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ABSTRACT 


Unmanned  tactical  autonomous  control  and  collaboration  (UTACC)  is  a  Marine 
Corps  experimental  research  initiative  with  the  overarching  aim  of  developing  a 
collaborative  human-robotic  system  of  systems  (SoS).  This  thesis  analyzed  the  results  of 
the  existing  UTACC  concept  development  and  incorporated  them  into  an  emergent 
human-robotic  system  development  method,  Coactive  Design.  An  advantage  to  using  this 
method  is  that  it  includes  the  human  and  his  or  her  internal  processes  when  modeling  the 
system.  As  such,  the  focus  is  shifted  to  supplementing  team  capacities  vice  developing 
autonomy. 

The  two  aims  of  this  thesis  are  (1)  to  provide  a  recommendation  for  incorporating 
the  Coactive  Design  method  into  the  systems’  development  life  cycle  and  (2)  to  provide  a 
list  of  design  requirements  for  a  resilient  UTACC  SoS.  Resilience  is  realized  by 
designing  for  flexibility.  A  teamwork  infrastructure  built  on  many  interdependent 
relationships  provides  this  flexibility.  These  interdependent  relationships  can  be  grouped 
into  three  areas:  observability,  predictability,  and  directability.  Counter  to  conventional 
practices  within  the  robotics  industry.  Coactive  Design  focuses  on  managing  these 
interdependencies  rather  than  focusing  on  autonomy.  Coactive  Design  also  provides  a 
cost-benefit  analysis  of  development  choices,  which  assists  with  developing  efficiencies 
during  the  design  and  development  of  the  system. 
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EXECUTIVE  SUMMARY 


This  thesis  is  part  of  an  ongoing  initiative  to  support  the  Unmanned  Tactical 
Autonomous  Control  and  Collaboration  (UTACC)  effort  sponsored  by  the  Marine  Corps 
Warfighting  Laboratory  (MCWL).  UTACC  is  being  designed  as  a  system  of  systems 
(SoS)  that  includes  autonomous  air  and  ground  components  geared  to  provide 
intelligence,  surveillance,  and  reconnaissance  (ISR)  for  support  of  Marine  Corps  tactical 
units.  What  separates  UTACC  from  other  such  systems  is  the  collaborative  nature  of  the 
interdependent  human-machine  (H-M)  team.  The  UTACC  system  is  being  developed 
through  an  iterative  and  incremental  design  process  as  a  means  of  satisfying  the  need  for 
exploratory,  technological  research  called  for  in  the  Marine  Corps’  current,  strategic  and 
visionary  planning  document.  Expeditionary  Force  21. 

UTACC  completed  its  initial  concept  development  in  2015  and  immediately  set 
about  defining  requirements  to  support  those  concepts.  The  search  for  a  methodology  that 
could  assist  with  accurately  capturing  these  requirements  and  relationships  that  support 
them  became  a  critical  investment  and  one  of  the  aims  of  this  thesis.  The  Coactive  Design 
method  was  chosen  for  analysis  of  any  potential  UTACC  suitability  due  to  the  acclaim 
for  the  method’s  architect.  Dr.  Matthew  Johnson,  from  the  2013  Defense  Advanced 
Research  Projects  Agency’s  (DARPA)  Virtual  Robotics  Challenge  (VRC)  and  the  2015 
DARPA  Robotics  Challenge  (DRC).  Coactive  Design  is  an  emergent  H-M  design  method 
that  helps  decipher  high-level  teaming  concepts  into  reusable  and  programmable  controls, 
interface  components,  and  behaviors  that  allow  machines  to  act  as  teammates. 

Coactive  Design  is  based  on  the  concept  of  interdependence  among  humans  and 
machines  operating  as  a  team  in  order  to  accomplish  a  mission.  These  coactively 
designed  interdependencies  are  broken  down  into  three  categories:  observability, 
predictability,  and  directability.  This  interdependence  framework  runs  counter  to  the 
conventional  H-M  system  design  wisdom,  which  seeks  to  increase  levels  of  system 
autonomy  or  human  independent  actions.  The  Interdependence  Analysis  (lA)  Tables  are 
the  tool  that  Coactive  Design  uses  to  generate  system  requirements.  The  tables 

decompose  tasks  into  the  most  elemental  capacities  required  in  order  for  these  tasks  to  be 

xvii 


performed.  After  task  decomposition,  each  individual  capacity  is  studied  within  the 
context  of  the  H-M  relationships  and  requirements  are  then  derived  that  help  support 
those  relationships. 

This  thesis’s  research  has  had  several  impact  areas  on  the  UTACC  initiative.  First, 
Coactive  Design  provides  UTACC  a  list  of  detailed  system  design  requirements.  Second, 
Coactive  Design  offers  UTACC  a  means  of  achieving  a  resilient  system  by  designing 
alternate  pathways  for  recognizing  and  managing  uncertainty.  These  pathways  were 
realized  as  a  result  of  the  analysis  conducted  using  the  lA  Tables,  and  provide  the  H-M 
team  flexibility  in  the  way  the  team  approaches  the  tasks  and  how  the  team  adapts  to 
problems  in  tactical  situations.  Third,  this  thesis  provides  recommendations  on  which 
capacities  UTACC  should  focus  on,  given  its  limited  developmental  time  and  resources. 
As  was  the  case  with  the  system  flexibility  provided  through  alternative  teaming 
pathways,  the  design  and  development  efficiencies  are  also  a  direct  byproduct  of  the  lA 
Table  analysis.  Lastly,  the  UTACC  specific  Coactive  Design  has  the  added  benefit  of 
fusing  and  preserving  several  preceding  UTACC  efforts.  For  these  reasons,  the  author 
recommends  incorporating  Coactive  Design  into  the  entire  development  life  cycle  for 
UTACC,  and  suggests  that  this  design  method  be  considered  for  all  of  the  Marine  Corps’ 
future  H-M  system  development  projects. 
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INTRODUCTION 


This  thesis  is  part  of  an  ongoing  initiative  to  support  the  Unmanned  Tactical 
Control  and  Collaboration  (UTACC)  effort  sponsored  by  the  Marine  Corps  Warfighting 
Laboratory  (MCWL).  The  UTACC  system  is  being  developed  through  an  iterative  and 
incremental  design  process.  As  such,  similarities  exist  between  this  work  and  that 
conducted  both  previously  and  in  parallel.  This  thesis  expands  and  utilizes  many  of  the 
results  and  products  developed  under  previous  Naval  Postgraduate  School  UTACC 
theses.  The  results  of  these  authors’  works  were  used  to  develop  concurrent  work  for 
other  such  theses. 

A.  SPONSORING  COMMAND,  OBJECTIVE,  AND  RESULTS 

MCWL  is  the  parent  command  for  the  experimental  UTACC  initiative.  The 
UTACC  system  is  being  designed  as  a  system  of  systems  (SoS)  that  includes  autonomous 
air  and  ground  components  geared  to  provide  intelligence,  surveillance,  and 
reconnaissance  (ISR)  for  support  of  Marine  Corps  tactical  units.  The  intent  behind  this 
thesis  is  to  develop  requirements  for  the  interface  that  allows  the  human  component  of 
the  UTACC  team  to  communicate  with  the  robotic  elements  and  vice  versa.  These 
requirements  will  offer  the  system’s  engineers  vital  Marine  Corps  user  perspective  that 
will  aid  in  the  speed  and  ease  of  adopting  the  system  at  the  user  level.  In  their  book. 
Switch,  Chip  and  Dan  Heath  discussed  organizational  change  to  stress  the  importance  of 
why  soliciting  and  building  user  preferences  from  the  beginning  of  the  design  and 
development  phase  is  important  for  enterprise-level  adoption  during  transformational 
change  periods  (2010). 

The  author  has  operational  experience  with  Marine  Corps  unmanned  aerial  and 
ground  systems;  however,  the  author  is  not  familiar  with  the  UTACC  proposed  level  of 
autonomy  and  collaborative  capabilities.  This  operational  experience  will  serve  as  an 
initial  litmus  test  for  use  case  development  and  will  also  provide  user  perspective,  a  key 
ingredient  for  interface  design.  These  interface  design  requirements  will  be  derived  from 
Marine  Corps  tactics,  techniques,  and  procedures,  as  well  as.  Marine  Corps  doctrinal  and 
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warfighting  publications  in  order  to  ensure  continued  relevancy  to  the  Marine  Corps  in 
the  future. 

B.  RETURN  ON  INVESTMENT  TO  MARINE  CORPS  WARFIGHTING  LAB 

As  technology  continues  to  rapidly  advance,  the  UTACC  system  offers  the 
Marine  Corps  the  opportunity  to  expand  its  capabilities,  controlling  the  pace  with  which 
advanced  autonomous  robotics  are  incorporated  into  warfare.  The  coactive  design 
methodology  and  tools  are  invaluable  to  UTACC’ s  design  process.  Coactive  design  helps 
decipher  high  level  teaming  concepts  into  reusable  and  programmable  controls,  interface 
components,  and  behaviors  that  allow  machines  to  act  as  teammates  (Johnson,  2014). 
Within  the  UTACC  construct,  the  defining  of  the  interdependent  relationships  between 
human  and  machines  provides  MCWL  with  another  critical  payoff.  This  paradigm  shift 
from  dependent  to  interdependent  relationships,  along  with  an  in-depth  understanding  of 
what  interdependence  means,  comprises  a  revolution  within  the  robotic  design  and 
development  disciplines.  Those  who  use  this  concept  as  the  crux  of  their  design 
framework  are  rewarded  with  an  empirical  competitive  advantage  in  the  form  of 
increased  observability,  predictability,  and  directability  between  Marines  and  unmanned 
components. 

C.  RESEARCH  METHODOLOGY  OVERVIEW 

As  a  small  portion  of  the  UTACC  initiative,  this  thesis  utilizes  concepts  from 
command,  control,  communications,  computers,  and  intelligence  (C4I)  literature  for 
building  the  requirements  of  the  UTACC  system.  The  requirements  are  built  from  the 
concept  design  conducted  in  Rice’s,  Keim’s,  and  Chhabra’s  (2015)  UTACC  thesis  work. 
The  core  of  the  Rice  et  al.’s  (2015)  work  came  in  the  form  of  MCWL-approved  task 
analysis  worksheets.  These  worksheets  built  upon  the  Marine  Corps  Troop  Leading 
Steps,  BAMCIS:  begin  the  planning,  arrange  for  reconnaissance,  make  reconnaissance, 
complete  the  plan,  issue  the  order,  and  supervise  (USMC,  2002).  All  Marines  are  taught 
this  planning  process  during  their  basic  training,  and  it  serves  as  a  fundamental  building 
block  within  the  Marine  Corps  user  perspective.  This  thesis  aims  to  provide  the  system 
designers  and  engineers  such  a  perspective. 
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The  task  analysis  worksheets  were  studied  by  the  author  and  morphed  into  a  more 
easily  digestible  form  by  the  interdependence  analysis  (lA)  tables,  derived  from  those 
found  in  Johnson’s  (2014)  doctoral  thesis  on  Coactive  Design.  lA  tables  break  down 
complex  tasks  into  their  most  elemental  sub-tasks  and  further  to  capacities  required  to 
complete  the  job.  Once  all  of  the  worksheets  were  imported  into  the  I A  tables,  the  author 
refined  and  filled  in  gaps  that  were  not  identified  by  the  Rice  et  al.  (2015)  team  but  were 
essential  to  the  accomplishment  of  the  overarching  tasks  they  proposed.  Then,  each 
individual  capacity  was  analyzed  against  all  viable  teaming  role  alternatives  (e.g.,  robot 
or  human)  to  see  which  was  more  capable  of  filling  the  requirement  and  to  what  extent 
the  other  teammates  were  able  to  assist.  In  this  way,  the  interdependent  relationships  of 
the  teammates  were  mapped  out.  The  author  then  extrapolated  requirements  for  the 
System-Marine  interfaces  that  will  serve  to  enable  these  interdependent  relationships. 

D.  RELATED  WORK 

This  thesis  complements  other  theses  conducted  in  the  UTACC  program.  Rice, 
Keim,  and  Chhabra  (2015)  and  Batson  and  Wimmer  (2015)  were  the  predecessors  of  this 
thesis  work  and  formed  the  foundation  of  this  thesis.  The  work  of  Kirkpatrick  and 
Rushing  is  in  progress  at  the  time  of  this  writing  and  focuses  on  mapping  the 
requirements  also  identified  in  this  thesis  to  measures  of  performance  (MOPs)  and 
measures  of  effectiveness  (MOEs).  The  work  of  Larreur  is  also  in  progress  and  focuses 
on  establishing  a  roadmap  of  experimentation  to  validate  the  requirements  of  this  thesis 
and  evaluate  the  MOPs  and  MOEs  suggested  in  Kirkpatrick’s  and  Rushing’s  work. 

Johnson’s  (2014)  work  and  preceding  publications  on  interdependence, 
autonomy,  and  especially  Coactive  Design  were  of  critical  importance  to  this  thesis. 
Johnson  (2014)  developed  the  Coactive  Design  model  and  interdependence  analysis 
tables  for  use  within  a  single  human-single  machine  teaming  environment  that  this  author 
modified  to  the  many  humans-many  machines  environment  unique  to  UTACC. 

E.  NEED  FOR  COACTIVE  DESIGN  WITHIN  UTACC 

Coactive  Design  offers  MCWE  a  methodical,  efficient,  and  user  centric  iterative 

process  for  building  UTACC.  It  is  a  method  for  designing  interdependent  systems  that 
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uses  a  design  tool  called  an  interdependence  analysis  table,  which  details  human-machine 
requirements.  The  requirements  guide  implementation  of  the  system,  providing  teamwork 
infrastructure.  The  accumulation  of  all  the  capabilities  under  the  teamwork  infrastructure 
determines  the  runtime  options,  which  determine  performance  (Johnson,  2014).  The 
flexibility  provided  by  these  options  will  equate  to  a  vastly  resilient  UTACC  system. 

F.  CHAPTER  SUMMARY 

This  chapter  has  provided  a  broad  overview  of  UTACC  and  described  why  the 
program  is  necessary  within  the  backdrop  of  the  Marine  Corps’  Expeditionary  Force  21 
(EF21).  As  a  result  of  this  necessity,  MCWE,  as  the  sponsoring  unit  for  this  program, 
serves  to  benefit  by  continuing  to  invest  with  UTACC.  MCWE’s  ROI  will  see 
improvements  in  both  time  to  market  and  user  acceptance  if  Coactive  Design  is  adopted 
into  the  development  life  cycle  of  this  program.  Furthermore,  this  thesis  offers  the  dual 
benefit  of  preserving  the  previous  UTACC  research  efforts  and  in  guiding  parallel  efforts. 
The  most  important  product  from  this  thesis  is  the  list  of  system  and  user  interface 
requirements,  which  were  derived  from  the  Coactive  Design  research  methodology. 

This  UTACC  specific  Coactive  Design  merges  several  preceding  works.  The 
most  influential  of  those  efforts  being  the  work  of  Johnson  (2014),  a  revolution  within 
human-machine  teaming,  and  that  of  Rice  et  al.  (2015),  the  UTACC  concept 
development  team.  The  next  chapter  explores  these  works  in  greater  detail. 
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II.  LITERATURE  REVIEW 


A.  UNMANNED  TACTICAL  CONTROL  AND  COLLABORATION 

Unmanned  Tactical  Control  and  Collaboration  (UTACC)  is  a  developing  research 
effort  concerned  with  human  and  machine  teaming  within  the  backdrop  of  the  United 
States  Marine  Corps.  The  tactical  application  of  UTACC  is  of  interest  to  the  Marine 
Corps  Warfighting  Laboratory  (MCWL)  as  it  explores  the  stated  need  for  innovative  and 
exploratory  technological  research  called  for  in  Expeditionary  Force  21  (EF21).  EF21 
(2014)  serves  as  the  Marine  Corps’  current  strategic  and  visionary  planning  tool  that  will 
help  shape  the  force  of  the  future.  The  Marine  Corps  Combat  Development  Command 
(MCCDC)  recognizes  that  many  of  the  initiatives  with  potential  value  offerings  are  not 
fully  mature  yet  (MCCDC,  2014).  However,  MCCDC  (2014)  requires  deliverables  that 
aid  in  the  development  of  future  force  capabilities.  The  UTACC  coactive  design  products 
within  this  paper  and  paralleling,  complementary  research,  if  certified  by  MCWL,  qualify 
for  these  future  force  capability  shaping  deliverables. 

Military  technology  advances  in  the  unmanned  systems  arena  provide  new 
capabilities  while  outsourcing  current  human  performed  tasks.  This  next  generation  of 
warfare  research  is  aimed  at  lessening  the  cognitive  load  of  humans  as  the  interactions 
between  humans  and  machines  become  more  complex.  To  this  end.  Rice,  Keim,  and 
Chhabra  (2015)  identified  the  user  interface  as  one  of  the  most  significant  pieces  of  the 
UTACC  system,  as  it  bridges  the  gap  between  constantly  evolving  robotic  agents  and  the 
humans  that  they  must  work  with.  This  thesis  further  develops  such  previous  UTACC 
research  efforts.  It  proposes  interface  and  systems  design  requirements  that  aim  to  bring 
these  UTACC  concepts  to  life.  The  design  requirements  are  the  direct  result  of  the 
application  of  the  coactive  design  method.  Johnson’s  (2014)  doctoral  thesis  proposed  the 
coactive  design  process  as  a  new  approach  to  dissecting  the  nuanced  interdependencies 
between  humans  and  machines  engaged  in  joint  activity.  This  design  process  makes  it 
possible  for  high-level  concepts  like  collaboration  and  teamwork  to  be  translated  into 
requirements  implementable  through  algorithms  and  programming  behavioral  logic. 
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B.  UTACC  VISION  AND  OVERVIEW 


MCWL  signed  a  FY14  statement  of  work  (SOW)  that  proposed  tasks  for  UTACC 
to  conduct  over  the  following  three  years;  the  end  state  being  the  production  of  a 
“decision-centric,  semi-autonomous,  distributive,  multi-agent,  multi-domain  robotic 
system”  (Statement  of  Work  [SOW],  2014,  p.  1).  In  order  to  accomplish  this,  UTACC 
leverages  collaborative  autonomy  to  significantly  reduce  operator  interaction  with  robotic 
systems  while  not  limiting  the  system’s  ability,  thus  improving  human  performance  and 
promoting  mission  success.  Under  the  SOW  (2014),  the  UTACC  system  encompasses 
both  semi- autonomous  unmanned  ground  and  air  vehicles  in  addition  to  the  human 
element. 

Developed  with  a  modular  system  of  systems  (SoS)  approach,  UTACC  is 
designed  to  be  scalable  and  adapt  over  time  to  encompass  additional  missions,  adapt  to 
new  conditions,  and  rise  to  evolving  threats  (SOW,  2014).  A  reconnaissance  mission  was 
chosen  as  the  initial  frame  of  reference  for  building  out  the  initial  UTACC  concept 
development.  Within  this  single  Marine  Corps  mission  a  small  tactical  team  of  four 
Marines,  commonly  referred  to  as  a  fire  team,  would  serve  as  the  human  element  within 
the  greater  UTACC  construct  (Rice  et  ah,  2015). 

C.  EXPEDITIONARY  FORCE  21 

Published  in  March  2014,  EF21  serves  as  the  Marine  Corps’  new  capstone 
concept,  having  replaced  the  Marine  Corps  Vision  and  Strategy  2025.  It  promotes  plans, 
aligns  future  concepts  and  creates  capability  roadmaps  (EF21,  2014).  Part  of  the  modem 
force  attributes  described  within  EF21  (2014)  is  the  ability  to  exploit  innovative  concepts 
and  methods  allowing  the  Marine  Corps  to  maintain  its  decisive  edge  over  adversaries. 
UTACC  offers  to  sharpen  that  edge  through  increased  fidelity  in  planning  coupled  with 
the  reduction  in  workload  for  the  human  operators  during  critical  periods  of  the  mission. 
Furthermore,  UTACC  seeks  to  leverage  the  Marine  Corps  traditional  operating  practices 
while  building  this  SoS,  with  the  users  in  mind  from  the  very  inception. 

Marine  Corps  Warfighting  and  Doctrinal  Publications  (MCWPs  and  MCDPs) 
reinforce  the  concept  and  interface  design  processes.  Gathering  requirements  from 
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Marine  Corps  missions,  strategic  vision,  and  publications  allows  for  ease  of  integration 
and  employment  of  the  system  of  systems  (SoS).  This  development  method  is  initially 
more  time  intensive  than  adopting  civil  technologies  within  similar  enterprises  (Bernard, 
2012).  However,  it  does  offer  a  more  effective  implementation  plan  than  incorporating 
the  requirements  at  the  end  of  development  (Bernard,  2012). 

EF21  (2014)  called  for  the  Marine  Corps  to  relentlessly  pursue  its  return  on 
investment  across  the  enterprise  while  seeking  these  innovative  approaches  to  capability 
development.  The  results  of  this  thesis  achieve  this  for  UTACC;  the  main  outputs  provide 
system  designers  with  tailored  requirements  for  the  system  interface.  It  has  also  allowed 
other  complementary  research  to  continue  in  parallel,  such  as  research  supporting 
measures  of  performance  and  measures  of  effectiveness  (MOPs  and  MOEs).  The  forward 
deployed  posture  that  EF21  envisions  projects  one-third  of  the  operating  forces  aboard. 
The  final  UTACC  SoS  offers  the  potential  to  redefine  the  Marine  Corps  enterprise.  These 
could  be  realized  in  reductions  to  manning  and  the  task  organization  of  infantry  battalions 
and  company  landing  teams,  the  Marine  Corps’  standard  deployment  unit  capable  of 
securing  landing  sites  or  maneuvering  to  deep  inland  objectives  during  entry  operations 
(EF21,  2014).  These  discussions  will  serve  as  areas  requiring  future  research. 

D.  UTACC  CONCEPT  OF  OPERATIONS 

UTACC  Concept  of  Operations,  or  concept  design,  was  the  thesis  work  of  Rice, 
Keim,  and  Chhabra  (2015),  which  set  the  stage  for  all  follow  on  work  within  UTACC.  It 
fits  within  the  systems  analysis  and  design  process  described  by  Satzinger,  Jackson,  and 
Burd  (2012),  which  is  where  this  thesis  continues.  Specifically,  Rice  et  al.’s  (2015) 
research  captured  the  system  requirements,  logical  sequencing  of  operational  activities, 
and  developed  a  model  for  mission  planning  and  execution.  Without  these  three 
functional  areas,  the  UTACC  coactive  design  model  would  not  have  been  possible.  A 
summary  of  these  functional  areas  follows. 

1.  UTACC  System  Requirements 

The  SOW  (2014)  provides  MCWE’s  endorsement  of  Rice  et  al.’s  (2015) 

constraints  for  the  final  system’s  capabilities.  They  are  summarized  as: 
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•  Adaptive  behaviors  providing  reduced  operator  workload 

•  Collaborative  command  and  control 

•  Distributive  and  modular  architectural  infrastructure 

•  Distributive  processing  and  storage 

•  Organic  mapping  and  obstacle  avoidance 

•  Autonomous  system  diagnostics 

•  Ease  of  maintenance 

•  Organic  power  operation  (SOW,  2014,  pg.  2) 

Reducing  the  current  workload  of  the  humans  in  the  team  is  central  to  the 
fundamental  purpose  of  UTACC.  Tangent  to  this  constraint  is  the  ability  of  all  components 
to  collaborate  their  individual  sensing  and  collecting  capabilities.  An  integrated  system 
interface  provides  the  means  to  communicate  this  information  back  and  forth  between 
human  and  robot.  Distributing  functionality  and  making  components  modular  allows  the 
system  to  continue  the  mission  should  a  single  component  be  removed  from  the  task.  The 
UTACC  system  must  be  able  to  map  its  surroundings  and  avoid  obstacles  as  it  moves 
throughout  the  battlespace  while  collecting  and  sensing.  Each  system  element  must  monitor 
its  sensors’  health,  communication  links  to  the  team,  and  fuel  status.  Due  to  the 
expeditionary  nature  of  these  small  tactical  teams,  the  elements  must  be  durable,  allow  for 
basic  field  maintenance,  and  must  operate  under  their  own  power. 

2.  Sequence  of  Operational  Activities 

Rice  et  al.  (2015)  adapted  the  Marine  Corps’  troop-leading  steps:  begin  planning; 
arrange  for  reconnaissance;  make  reconnaissance;  complete  the  plan;  issue  the  order;  and 
supervise  activities  (BAMCIS)  as  the  groundwork  for  building  the  functional  UTACC 
model.  These  steps  are  important  to  the  UTACC  coactive  design  process  because  they 
serve  as  the  highest  level  of  organization  within  the  UTACC  coactive  design  model.  The 
following  quote  from  the  Marine  Rifle  Squad  (USMC,  2002)  publication  defines 
BAMCIS  as: 
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The  troop-leading  procedures  listed  below  are  aids  in  preparing  for  and 
executing  assigned  missions.  They  assist  squad  and  fire  team  leaders  in 
making  the  best  use  of  time,  facilities,  and  personnel.  All  the  steps  should 
be  considered,  but  depending  upon  the  mission  and  time  available,  the 
degree  of  consideration  for  each  will  vary. 

Begin  Planning.  When  an  order  is  received,  the  squad  leader  considers  the 
time  available  to  him.  In  so  doing,  he  uses  a  planning  sequence  called 
reverse  planning,  meaning  that  he  starts  with  the  last  action  for  which  a 
time  is  specified  (e.g.,  an  attack)  and  works  backward  to  the  issuing  of  his 
order.  This  helps  ensure  that  enough  time  is  allowed  for  the  completion  of 
all  necessary  actions.  During  this  stage,  he  also  analyzes  the  terrain  and 
the  friendly  and  enemy  situation.  From  his  analysis,  he  formulates  a 
preliminary  plan  of  action  to  accomplish  the  mission.  This  plan  is  only 
tentative  and  will  often  be  changed. 

Arrange  for  Reconnaissance  and  Coordination.  The  squad  leader  selects  a 
route  and  prepares  a  schedule  for  reconnaissance  and  coordination  with 
adjacent  and  supporting  units.  Normally,  he  takes  his  fire  team  leaders  and 
the  leaders  of  any  attached  crew-served  weapons  teams  with  him  on  his 
reconnaissance. 

Make  Reconnaissance.  On  his  reconnaissance,  the  squad  leader  completes 
his  estimate  of  the  situation.  Prearranged  meetings  with  adjacent  squads 
and  supporting  units  are  held  as  scheduled.  He  notes  how  the  terrain 
affects  his  preliminary  plan  and  adopts,  alters,  or  ejects  it  as  necessary. 

While  on  his  reconnaissance,  he  selects  advantage  point  from  which  to 
orient  his  fire  team  leaders. 

Complete  Plan.  Upon  his  return  from  the  reconnaissance,  the  squad  leader 
completes  his  plan  of  action.  He  then  prepares  notes  to  be  used  in  issuing 
his  order. 

Issue  Order.  If  possible,  the  squad  leader  issues  his  order  to  the  same 
personnel  he  took  with  him  on  his  reconnaissance  from  the  vantage  point 
he  had  selected  earlier.  If  this  is  not  possible,  the  team  leaders  are  oriented 
from  maps,  sketches,  or  an  improvised  terrain  model.  He  issues  his  order 
using  the  five-paragraph  order  sequence  and  includes  everything  his  fire 
team  and  attached  weapons  leaders  need  to  know. 

Supervise  Activities.  The  squad  leader  continuously  supervises  his  unit  to 
ensure  that  his  order  is  carried  out  as  intended.  (2002,  pp.  C1-C2) 

These  steps  form  a  logical  sequence  of  iterative  events  that  allow  Marines  to 
conduct  all  pre-mission  activities  while  ensuring  a  high  likelihood  of  success  during  the 
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execution  phase.  The  BAMCIS  process  is  uniquely  suited  for  implementation  as  the 
backbone  of  the  UTACC  concept  of  operations  due  to  the  close  familiarity  that  all 
Marines  have  with  it.  Figure  1  is  a  graphical  depiction  of  these  concepts. 


Figure  1.  Marine  Corps  Troop-Leading  Steps  (BAMCIS) 


Source:  Rice,  T.,  Keim,  E.  A.,  Chhabra,  T.  (2015).  Unmanned  tactical  autonomous 
control  and  collaboration  concept  of  operations.  (Master’s  thesis).  Naval  Postgraduate 
School.  Retrieved  from  Calhoun  http://calhoun.nps.edu/handle/10945/47319. 


3.  Mission  Planning  and  Execution  Model 

With  these  human  centric  procedures  in  mind,  Rice  et  al.  (2015)  explored 
incorporating  the  machine  aspects  of  UTACC  into  the  fold  of  the  reconnaissance  mission 
use  case.  The  next  step  from  a  systems  analysis  and  design  perspective  was  to  create  an 
activity  diagram,  a  depiction  of  the  complex  flow  of  activities  occurring  within  each 
phase  of  BAMCIS  (Satzinger,  Jackson,  Burd,  2012).  The  activity  diagram,  or  mission 
planning  and  execution  model,  is  shown  in  Figure  2.  Each  row  within  this  model 
represents  a  phase  of  BAMCIS  and  has  specific  activities  and  decision  points  that  must 
be  completed  by  a  component  of  the  UTACC  team.  These  activities  are  of  significant 
importance  to  the  Coactive  Design  process.  Each  one  is  broken  down  into  its  most 
fundamental  capabilities.  Each  capability  is  then  processed  and  the  outputs  come  in  the 
form  of  the  system  and  user  interface  requirements.  (This  process  will  be  broken  down  in 
further  detail  during  the  discussion  on  Interdependence  Analysis  Tables.) 
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Figure  2.  Mission  Planning  and  Execution  Model 


Source;  Rice,  T.,  Keim,  E.  A.,  Chhabra,  T.  (2015).  Unmanned  tactical  autonomous 
control  and  collaboration  concept  of  operations.  (Master’s  thesis).  Naval  Postgraduate 
School.  Retrieved  from  Calhoun  http://calhoun.nps.edu/handle/10945/47319. 
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As  seen  in  Figure  2,  the  BAMCIS  steps  are  separated  into  their  own  swim  lanes 
on  the  left  hand  side  of  the  figure.  The  activities  that  are  identified  as  unique  to  each  step 
are  then  listed  in  a  flow  chart  fashion  to  the  right  of  the  step.  This  depiction  easily  guides 
a  system’s  designer  to  understand  the  flow  of  work  from  initiation  to  completion,  while 
each  activity  fits  within  the  Marine  Corps  user’s  troop  leading  perspective. 

4.  Task  Analysis  Worksheets 

The  activities  within  Figure  2,  Mission  Planning  and  Execution  Model,  are 
collective  events  that  define  the  interdependent  relationships  between  man  and  machine. 
Each  activity  is  comprised  of  many  individual  subtasks  and  competencies  that  require 
further  elucidation.  Rice  et  al.  (2015)  created  multiple  reference  documents  to  assist  with 
these  explanations,  which  are  referred  to  as  task  analysis  worksheets.  System  modelers, 
while  prototyping,  can  use  these  documents  to  understand  not  only  the  breakdown  of 
work  but  also  the  Marine  Corps  doctrinal  reasoning  behind  why  certain  activities  must  be 
performed.  These  documents  have  been  incorporated  into  the  coactive  design  model. 

Eigure  3  depicts  a  generic  worksheet  and  provides  descriptions  of  each  field.  The 
worksheets  are  broken  down  into  three  separate  sections:  administrative  data,  planning 
factors,  and  UTACC  actions.  The  administrative  data  was  utilized  within  the  coactive 
design  process  in  order  to  assist  with  ordering  the  high-level  tasks.  Planning  factors 
identified  additional  tasks  and  capabilities  that  needed  to  be  incorporated  into  the 
Coactive  Design.  Einally,  UTACC  actions  were  carried  over  where  appropriate  and 
included  in  the  Coactive  Design  output  list  of  system  and  interface  requirements. 
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Figure  3.  Task  Analysis  Worksheet  Strueture 
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Task  Summary 
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complete  the  task 

Reference  Documents 
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Planning  Factors 

Threat  Analysis 

A  synopsis  of  the  role  of  the  threat/adversary  that  affect  task 
performance 

Conditions 

The  variables  of  the  environment  that  affect  task  performance 

Assumptions 

Events  assumed  to  be  true  in  the  absence  of  facts  in  order  to 
continue  planning 

Resources 

The  components  and  subcomponents  of  UTACC  that  will  be 
utilized  to  complete  this  task 

Specified  Tasks 

Tasks  specifically  given  by  higher  headquarters 

Implied  Tasks 

Tasks  not  specifically  stated  by  higher  headquarters  but  are 
necessary  to  accomplish  specified  tasks 

Limitations 

Constraints:  What  must  be  done 

Restraints:  What  cannot  be  done 

Shortfalls 

Resources  required  to  accomplish  the  task  that  are  not  organic  to 
UTACC 

UTACC  Actions 

Inputs 

Elements  required  for  the  task  to  be  accomplished  (e.g.,  tangible 
resources,  information  requirements,  etc.) 

Process 
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team 

Outputs 

The  results  of  the  process  given  specific  inputs 

Associated  lERs 

A  list  of  relevant  lERs  affected  during  the  process 

Source:  Rice,  T.,  Keim,  E.  A.,  Chhabra,  T.  (2015).  Unmanned  tactical  autonomous 
control  and  collaboration  concept  of  operations.  (Master’s  thesis).  Naval  Postgraduate 
School.  Retrieved  from  Calhoun  http://calhoun.nps.edu/handle/10945/47319 
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As  a  future  warfighting  concept,  an  important  aspect  of  these  worksheets  is  how 
they  tie  to  Marine  Corps  reference  documents.  Rice  et  al.  (2015)  took  a  deliberate 
approach  to  align  these  worksheets  with  current  Marine  Corps  tactics,  techniques, 
procedures,  and  publications.  Tying  this  effort  to  doctrine  increases  the  likelihood  for 
longevity  of  UTACC  within  the  Marine  Corps  and  makes  it  easier  to  build  a  training  plan 
aligned  with  current  programs  of  record. 

E.  UTACC  RED  CELL 

As  a  developing  technology  based  warfighting  concept,  UTACC  faces  multiple 
security  threats  during  its  design  and  development  phases  through  to  its  implementation. 
Batson’s  and  Wimmer’s  (2015)  thesis,  UTACC  Red  Cell,  looked  at  multiple  threats  and 
vulnerabilities  facing  the  UTACC  system.  The  objective  of  the  research  was  to  mitigate 
vulnerabilities  and  facilitate  mission  success  of  UTACC  missions  (Batson  &  Wimmer, 
2015).  Their  initial  framework  for  these  threats  and  vulnerabilities  was  created  using  the 
National  Institute  of  Standards  and  Technology  (NIST)  Risk  Management  Framework 
(RMF)  and  DOD’s  Information  Assurance  Certification  and  Accreditation  Process 
(DIACAP).  The  authors  noted  the  framework  led  to  a  threat  analysis  template  that  broke 
down  UTACC’ s  inherent  vulnerabilities  and  provided  security  control  strategies  to 
mitigate  the  vulnerabilities.  Their  findings  were  separated  into  non-technical  and 
technical  categories  (2015).  The  following  quote  offers  a  brief  description  of  each  of 
these  categories: 

Within  the  non-technical  category  the  following  security  controls  emerged 
as  those  essential  to  threat  mitigation. 

•  Policies,  procedures  and  publications  must  be  analyzed  to 
determine  specific  UTACC  system  requirements.  Requirements 
lead  to  the  development  of  system  specifications  which  will  drive 
operational  employment,  training,  and  integration  of  the  system. 

•  The  UTACC  system  security  policies  and  procedures  must  be 
developed  to  meet  the  requirements  of  the  DOD  and  USMC. 

Ensure  the  UTACC  system  completes  the  DIACAP  process,  which 
ensures  the  system  meets  DOD  requirements  for  lA. 
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•  Adherence  to  USMC  Communications  Security  (COMSEC) 
standards  and  policies  which  includes  physical,  cryptographic, 
transmission,  and  emission  security. 

•  Training  pipeline  for  leaders,  planners,  and  operators  to  support  the 
UTACC  system  employment  by  a  USMC  unit. 

•  Extensive  testing  and  evaluation  with  operational  units.  (2015,  p. 

41) 

Technical  security  control  reoccurrences  do  not  form  as  much  of  a  visible  pattern 
in  the  research  due  to  the  specificity  of  the  technical  security  controls  to  the  individual 
threats.  The  one  security  control  that  stands  out  however  is  the  recommendation  for  the 
UTACC  system  to  incorporate  semi-autonomous  modes  of  operation.  This  security 
control  is  mentioned  in  27  of  the  29  templates.  Other  technical  security  controls  that 
emerged  as  those  necessary  to  mitigate  threats  follow: 

•  Remote  zeroing  of  software,  data,  and  cryptographic  material. 

•  Employ  tamper  resistant  technology. 

•  Independent  UGV  and  UAV  operations. 

•  Redundant  and  encrypted  C2  and  data  links  spread  across  the  EM 
spectrum. 

•  Ensure  the  UTACC  network  communication  links  are  separated 
from  the  USMC  communication  architecture  through  best  practices 
(boundary,  firewall,  router  access  control  lists.  Virtual  Eocal  Area 
Networks  [VEANS]).  (2015,  p.  42) 

These  strategies  were  considered  during  the  initial  coactive  design  process  while 
shaping  the  system  and  interface  design  requirements  and  should  be  woven  into  all  future 
UTACC  work.  Eailure  to  consider  the  security  and  cyber  aspects  of  the  system  at  any 
stage  of  the  development  process  could  introduce  weaknesses  that  a  potential  adversary 
could  then  exploit. 

F.  SYSTEMS  ENGINEERING 

The  importance  placed  on  attaining  quality  system  requirements  early  on  with 
feedback  from  stakeholders  is  of  critical  importance  to  keeping  any  large  scale,  complex 
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and  multi-disciplinary  system  within  cost  and  time  constraints  (Bernard,  2012).  This 
process  is  inherently  difficult  and  while  mueh  preparation  can  be  achieved  up  front  to  set 
initial  requirements,  continuous  communication  between  stakeholders  and  developers  is 
essential  throughout  the  development.  Filtering  out  the  issues  from  the  stakeholder’s 
wants  and  analyzing  them  against  system  boundaries,  functions,  and  scenarios  leads  to 
the  development  of  realistic  requirements.  These  requirements  can  then  be  used  in  the 
design  process  to  build  out  the  system  architecture. 

In  the  early  days  of  UTACC,  MCWL  recognized  that  many  of  the  processes 
which  the  UTACC  system  was  being  designed  to  perform  seemed  repeatable.  In  other 
words,  many  of  the  tasks  and  decisions  a  robot  might  make  while  working  toward 
accomplishing  a  given  task  were  seen  again  and  again,  in  other  similar  tasks.  Given  the 
scale  and  complexity  of  what  UTACC  was  attempting  to  accomplish,  it  became 
necessary  to  search  for  ways  of  streamlining  the  colleetion  of  these  requirements. 
UTACC  became  interested  in  the  coactive  design  process  as  a  way  to  efficiently  generate 
requirements  and  allow  for  this  streamlining  of  information  flows  to  the  system 
developers.  The  benefits  of  this  emergent  software  design  process  do  not  alleviate  it  from 
the  continuous  refinement  and  communication  needed  between  designers  and  developers 
however.  This  thesis  utilizes  the  coactive  design  process  to  produce  an  initial  list  of 
requirements  which  will  need  to  be  adjusted  and  added  to  as  the  system  is  put  through 
scenario  testing. 

G.  COACTIVE  DESIGN 

The  recent  work  done  by  Johnson  (2014)  on  coactive  design  offered  five  major 
contributions  to  the  field  of  human-robot  system  design:  a  fresh  design  perspective  built 
on  interdependence,  a  more  comprehensive  understanding  of  interdependence,  a  model 
for  human-machine  systems,  a  design  method,  and  a  new  tool  to  assist  with  system 
design  and  analysis  called  the  Interdependence  Analysis  (lA)  Table. 

I.  Interdependence 

The  foundation  of  coactive  design  resides  on  the  concept  of  interdependence.  This 

concept  is  a  two  way  reliance,  or  symbiotic  relationship,  between  people  and  machines  as 
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they  work  toward  the  same  goal.  It  is  this  view  that  sets  the  coactive  design  method  apart 
from  other  system  and  software  engineering  design  models.  It  is  viewed  by  Johnson 
(2014)  as  the  key  element  of  designing  collaborative  systems.  Johnson  (2014)  stated  that 
understanding  the  nature  of  the  interdependencies  between  humans  and  machines 
provides  insight  into  the  kinds  of  coordination  that  will  be  required.  Johnson  et  al.  (2011) 
asserted  that  coordination  mechanisms  in  skilled  teams  arise  largely  because  of  such 
interdependencies.  Interdependence  management  is  therefore  the  mechanism  by  which 
higher  level  ideas,  like  collaboration,  coordination,  and  teamwork  are  achieved  (Johnson 
2014). 

Many  modern  day  human-machine  systems  share  responsibility  between  both 
humans  and  machines,  although  the  automation  is  unaware  of  the  humans  in  the  activity. 
Klein  et  al.  (2005)  stated  that  joint  activity  implies  mutual  engagements  in  processes 
extending  in  time  and  space.  This  statement  stresses  the  importance  of  both  humans  and 
machines  and  how  they  interact  together  to  accomplish  the  goal.  Coactive  design  aims  to 
move  away  from  the  common  practice  of  allocating  tasks  to  machines  who  know  little 
about  the  overall  mission  goals  or  about  other  tasks  that  the  allocated  task  is  reliant  on 
(Johnson,  2014).  Cummings,  da  Silva,  and  Scott  (2007)  noted  that  current  practices 
ignore  the  collaboration  and  collective  decision  making  that  is  required  for  successful 
implementation.  Miller  (2012)  stated  that  a  significant  fault  with  supervisory  control 
frameworks,  where  tasks  are  delegated  to  machines  and  supervised  by  humans,  is  that  the 
rigidly  hierarchical  task  decompositions  that  they  are  based  upon  focus  only  on  the  act  of 
delegating  and  not  on  the  context  of  the  delegation.  These  studies  point  ardently  to  the 
fact  that  humans  must  be  integral  components  of  the  systems  and  not  merely  users  of  the 
systems. 

Macbeth,  Cummings,  Bertuccellie,  and  Surana  (2012)  stated  that  most  often 
system  users  are  not  considered  at  the  time  when  algorithm  designers  create  optimization 
algorithms,  and  that  these  optimizations  are  performed  even  before  the  interface 
designers  develop  the  interface  requirements  for  how  the  users  will  interact.  With  the 
focus  of  this  thesis  to  correct  that  design  failure,  the  users  are  being  considered  from  the 
beginning  and  are  being  looked  at  for  their  mutually  supporting  roles  throughout  the  task. 
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Interdependence  also  shapes  the  autonomy  of  the  systems.  Johnson  (2014)  stated 
that  the  levels  of  self-sufficiency  and  self-directedness  are  very  situationally  dependent 
and  rely  heavily  on  properly  understanding  the  interdependencies  between  members  of 
the  team  in  the  unique  activity  in  which  they  are  involved.  An  agent’s  autonomous 
capabilities  can  thus  be  shaped  during  design  and  implementation  to  enable  correct 
interactions  with  both  people  and  other  agents  (Johnson,  2014). 

2.  Autonomy 

Prior  to  the  development  of  the  coactive  design  methodology,  Johnson  et  al. 
(2011)  investigated  the  leading  popular  design  approaches  to  human-machine  teaming. 
Specifically,  those  approaches  were  autonomy-centered  which  presented  limited  results 
as  they  did  not  capture  the  necessary  give  and  take  relationships  between  all  agents.  It  is 
now  well  known  in  the  automation  industry  that  automating  processes  does  not 
necessarily  simplify  complex  situations.  In  fact,  it  most  often  has  the  inverse  effect, 
creating  even  greater  need  for  control  and  understanding  of  the  situation  early  in  planning 
stages. 

Johnson  (2014)  reviewed  Parasuraman’s,  Sheridan’s,  and  Wickens’  (2000)  scale 
on  the  levels  of  autonomy,  which  solely  focused  on  the  computer’s  process  of  decision¬ 
making,  and  viewed  it  as  useless  to  assisting  the  designer  as  it  lacked  human  performance 
measures.  Proud,  Hart,  and  Mrozinski  (2003)  adapted  the  Parasuraman  et  al.  (2000)  scale 
by  incorporating  the  necessary  human  performance  measures  within  the  context  of  the 
varying  levels  of  autonomy.  It  parallels  the  theme  of  interdependence  making  it  relevant 
to  the  coactive  design  approach,  and  is  presented  in  Figure  4. 
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Figure  4.  Levels  of  Autonomy  Assessment  Scale 
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Figure  4  possesses  a  level  of  autonomy  axis  and  an  observe,  orient,  decide,  and 
act  (OODA)  loop  axis.  OODA  was  developed  by  the  military  as  an  attempt  to  disrupt  the 
enemy’s  processes  of  decision  making.  It  is  a  familiar  concept  to  all  Marines,  taught  early 
in  entry  level  training  and  referred  to  regularly  thereafter.  Proud,  et  al.  (2003)  tailored 
each  level  of  autonomy  to  fit  the  tasks  within  each  function  of  OODA.  The  Observe 
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column  encompasses  gathering,  monitoring,  and  filtering  data;  the  orientation  column 
encompasses  analysis,  prediction,  and  interpretation;  the  decision  column  refers  to 
ranking  options  and  choosing  one;  the  action  column  refers  to  execution  of  the  option 
chosen  (Proud  et  al.,  2003).  The  levels  of  autonomy,  range  from  the  lowest  level,  level  1, 
where  the  human  is  fully  responsible  for  all  actions  performed  with  respect  to  OODA,  to 
the  highest  level,  level  8,  where  the  system  is  fully  responsible  for  all  actions  (Proud  et 
ah,  2003). 

While  the  coactive  design  method  as  developed  by  Johnson  (2014)  was  developed 
in  the  absence  of  Figure  4,  this  author  used  it  to  conceptualize  how  to  expand  the  single 
human-single  machine  dynamic  explored  in  Johnson’s  (2014)  studies  to  the  more 
complex  dynamic  presented  within  the  multiple  human-multiple  machine,  UTACC 
system.  The  UTACC  system  developers  can  use  the  construct  of  Figure  4  as  UTACC 
missions  mature  beyond  what  is  currently  being  explored  at  the  time  of  this  writing.  It  is 
necessary  to  stress  that  the  UTACC  system  is  not  envisioned  to  fall  within  one  particular 
level  of  this  scale  but  that  it  should  be  capable  of  being  placed  initially  into  a  level  and 
then  dynamically  adjusting  it  throughout  any  particular  mission  based  on  an  evolving 
situation.  Being  able  to  meet  this  demand  further  stresses  the  crucial  need  for 
understanding  the  complex  interdependencies  of  the  team. 

3.  Coactive  System  Model 

Having  stressed  the  importance  of  interdependence  and  what  it  means  to  be 
interdependent,  this  thesis  moves  next  to  the  model  for  human-machine  systems.  This 
model  emphasizes  how  managing  and  supporting  interdependent  relationships  is  possible. 
This  model  serves  as  a  means  for  guiding  the  designer  to  relevant  issues  needing  to  be 
addressed,  defines  appropriate  specifications,  and  also  aids  in  evaluating  alternatives. 

Johnson  et  al.  (2014)  viewed  Fong’s  (2001)  collaborative  control  method  as  the 
most  descriptive  model  existing  in  literature  at  the  time  of  their  research.  Fong’s  (2001) 
innovation  was  in  stating  that  the  human  should  be  permitted  to  make  perceptual  or 
cognitive  decisions  for  the  robot  through  a  user  interface  (UI)  that  the  robot  provides 
inputs  to.  Fong’s  (2001)  model  considered  the  internal  processes  of  the  robot  and  how 
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they  manifested  to  the  user  as  opposed  to  depicting  the  robot  as  a  black  box  of 
uncertainty.  In  modeling  how  perception  and  cognition  occurred  in  the  robot  there  were 
ways  to  vary  how  the  human  could  interact  with  them  (Fong,  2001).  Fong’s  (2001)  model 
was  suited  to  individual  activity — as  opposed  to  joint  activity — and  how  the  simple  tasks 
were  handed  off  from  human  to  robot.  This  method  more  closely  resembled  teleoperation 
of  a  robot  by  a  human  as  opposed  to  what  Johnson  et  al.  (2014)  sought  to  model,  which 
was  an  interdependent  relationship  through  the  conduct  of  a  joint  activity.  The  Johnson  et 
al.  (2014)  model  highlights  the  importance  of  internal  processes  similar  to  Fong’s  (2001) 
work  but  with  the  additional  requirements  necessary  to  conduct  joint  activity: 
observability,  predictability,  and  directability  (OPD);  it  is  presented  in  Figure  5. 

Figure  5.  Coactive  System  Model 


Source;  Johnson,  M.  (2014).  Coactive  design:  Designing  support  for  interdependence  in 
human-robot  teamwork.  Doctoral  dissertation.  Delft  University  of  Technology- 
Mekelweg/Netherlands. 


4.  Observability,  Predictability,  and  Directability 

The  following  quote  from  Johnson’s  (2014)  work  clarifies  what  it  means  to  be 
observable,  predicable,  and  directable: 
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Observability  means  making  pertinent  aspects  of  one’s  status  and 
knowledge  of  the  team,  task  and  environment  observable  to  others. 
Observability  also  involves  the  ability  to  observe  and  interpret  pertinent 
signals.  It  plays  a  role  in  many  teamwork  patterns  e.g.,  monitoring 
progress  and  providing  backup  behavior. 

Predictability  means  one’s  actions  should  be  predictable  enough  that 
others  can  reasonably  rely  on  them  when  considering  their  own  actions. 
Predictability  also  involves  considering  other’s  actions  when  developing 
one’s  own.  It  is  essential  to  many  teamwork  patterns  such  as 
synchronizing  actions  and  achieving  efficiency  in  team  performance. 

Directability  means  one’s  ability  to  direct  the  behavior  of  others  and 
complementarily  by  directed  by  others.  It  includes  explicit  commands 
such  as  task  allocation  and  role  assignment  as  well  as  subtler  influences, 
such  as  providing  guidance  or  suggestions  or  even  providing  salient 
information  that  is  anticipated  to  alter  behavior,  such  as  a  warning. 
Teamwork  patterns  that  involve  directability  include  such  things  as 
requesting  assistance  and  querying  for  input  during  decision  making. 

By  using  the  OPD  framework  as  a  guide,  a  designer  can  identify  the 
requirements  for  teamwork  based  on  which  interdependence  relationships 
the  designer  chooses  to  support.  The  framework  can  help  a  designer 
answer  questions  such  as  ‘What  information  needs  to  be  shared,’  ‘Who 
needs  to  share  with  whom,’  and  ‘When  is  it  relevant.’  The  goal  of  the 
designer  is  to  attain  sufficient  OPD  to  support  the  necessary 
interdependent  relationships.  (2014,  pp.  68-70) 

This  OPD  framework  shifts  the  focus  from  one  individual  component,  either  the 
robot  or  the  human,  to  the  team  components  and  how  they  both  affect  one  another 
(Johnson,  2014).  The  framework  separates  individual  task  accomplishment  from 
teamwork.  The  interface  represents  the  mechanism  required  to  support  this 
interdependence  (Johnson,  2014). 

5.  Coactive  Design  Method 

Conveying  abstract  concepts  like  coordination,  cooperation,  and  collaboration 
into  system  designer  friendly  forms,  or  system  requirements  implemented  through  control 
algorithms,  interface  features,  and  behaviors,  is  challenging.  The  coactive  design  method 
translates  these  complex  concepts  into  useful  system  requirements  by  managing 
interdependent  activities  (Johnson,  2014).  With  an  understanding  of  what  it  means  to  be 
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interdependent,  the  OPD  requirements,  and  the  Coaetive  Design  Model  it  is  now 
appropriate  to  eonsider  in  detail  the  Coactive  Design  Method,  illustrated  in  Figure  6. 


Figure  6.  Coactive  Design  Method 


Source:  Johnson,  M.  (2014j.  Coactive  design:  Designing  support  for  interdependence  in 
human-robot  teamwork.  Doctoral  dissertation.  Delft  University  of  Technology- 
Mekelweg/Netherlands. 
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As  seen  in  Figure  6,  the  Coactive  Design  Method  has  three  main  processes: 
identification,  selection  and  implementation,  and  evaluation  of  change.  Each  process  is 
then  further  broken  down  into  inputs,  sub-processes  and  lastly  outputs.  The  design  of 
Figure  6  can  be  misleading  as  the  steps  seem  to  flow  in  a  stepwise  fashion  from  block  to 
block  resembling  a  waterfall  design  process.  When  modeling  processes  with  a  waterfall 
design,  the  requirements  are  mostly  understood  upfront  and  allow  developers  to  move  on 
to  subsequent  phases  without  needing  to  revisit  previously  completed  phases  (Satzinger 
et  ah,  2012).  However,  the  feedback  loops  to  the  side  of  the  figure  are  of  critical 
importance  in  understanding  the  process  and  must  be  fully  conveyed  to  all  stakeholders 
invested  in  the  system’s  development.  These  loops  illustrate  that  the  Coactive  Design 
Method  contains  many  adaptive  elements  that  evolve  through  iteration,  which  is  what 
Satzinger  et  al.  (2012)  considers  spiral  modeling.  This  adaptive,  spiral  modeling  process 
not  only  suggests  that  the  identification,  selection  and  implementation,  and  evaluation 
processes  of  the  Coactive  Design  Method  be  repeated  but  necessitates  repetition  in  order 
to  produce  solutions  that  more  accurately  capture  the  interdependent  activity. 

a.  Identification  Process 

Johnson  (2014)  differentiated  the  Coactive  Design  Method  from  traditional  task 
analysis  techniques  through  its  unique  analysis  of  interdependence  by: 

•  Allowing  for  soft  constraints 

•  Allowing  for  more  types  of  interdependence  than  just  task  dependency 

•  Representing  other  participants  in  the  activity  by  name  or  by  role 

•  Allowing  for  assessment  of  capacity  to  perform 

•  Allowing  for  assessment  of  capacity  to  support 

•  Allowing  for  consideration  of  role  permutations 

The  identification  process  within  Coactive  Design  is  made  possible  through  an 
analysis  tool  that  Johnson  et  al.  (2014)  refers  to  as  the  Interdependence  Analysis  (lA) 
Table,  Figure  7.  This  author  adapted  the  Johnson  et  al.  (2014)  Interdependence  Analysis 
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Table  to  meet  the  larger,  many  human-many  machine,  UTACC  teaming  environment. 
The  adapted  UTACC  lA  Table  is  presented  in  the  following  chapters  of  this  thesis. 


Figure  7.  Interdependence  Analysis  Table 
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Source:  Johnson,  M.  (2014j.  Coactive  design:  Designing  support  for  interdependence  in 
human-robot  teamwork.  Doctoral  dissertation,  Delft  University  of  Technology- 
Mekelweg/Netherlands. 


Figure  6,  the  Coactive  Design  Method,  provides  guidance  on  how  to  navigate  and 
manipulate  the  lA  Table  depicted  in  Figure  7.  The  identification  process  begins  with 
traditional  task  analysis.  The  left  most  columns  of  the  lA  Table  break  down  tasks  into 
manageable  granularity.  Capacities  are  defined  as  the  knowledge,  skills,  and  abilities  that 
are  necessary  for  the  tasks.  These  include  perceptual,  decision  making,  and  specific 
action  needs  (Johnson,  2014).  The  next  sections,  moving  right  across  the  table,  enumerate 
the  team  role  alternatives  by  identifying  the  primary  actor  that  will  be  accomplishing  the 
task  and  the  remaining  team  mates  in  supporting  roles.  Alternatively,  a  different  actor 
may  serve  as  the  primary  with  a  different  cast  of  agents  in  supporting  roles.  In  listing 
these  alternatives  it  becomes  possible  to  identify  the  best  suited  team  member  for 
fulfilling  a  task  and  communicates  that  a  level  of  support  is  required  by  the  rest  of  the 
team.  After  alternatives  were  determined,  Johnson  (2014)  then  assessed  the  individual’s 
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ability  to  provide  the  required  capacity  or  ability  to  support  the  performer.  This 
assessment  is  made  possible  through  the  use  of  the  following  color  coding  scheme 
(Figure  8). 


Figure  8.  Interdependence  Analysis  Coloring  Scheme 
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Source:  Johnson,  M.  (2014j.  Coactive  design:  Designing  support  for  interdependence  in 
human-robot  teamwork.  Doctoral  dissertation.  Delft  University  of  Technology- 
Mekelweg/Netherlands. 


It  is  important  to  note  the  colors  take  on  different  meanings  with  respect  to 
describing  the  performer  verses  the  supporting  team  members.  The  performer  column 
breaks  down  the  individual’s  capacity  to  perform  a  task.  Colors  in  the  supporting  member 
column  indicate  potential  to  support  the  performer — and  not  the  ability  of  that  team 
member  to  do  the  task  themselves.  A  simple  example  of  how  the  differences  play  out 
may  illustrate  the  point  further.  In  the  case  of  a  robot  as  the  performer  and  a  human  as  a 
supporter,  the  robot  may  be  able  to  search  a  room  while  looking  for  an  object  all  on  its 
own.  However,  introduce  a  tall  table  into  the  room  and  place  the  object  on  it,  out  of  view 
of  the  robot,  and  the  robot  is  unable  to  complete  the  task  with  100  percent  reliability. 
Having  a  human  check  the  table  would  improve  that  reliability.  Shading  in  the  lA  Table 
would  then  color  the  performer  column  with  yellow  and  the  supporting  column  with 
yellow. 

Coloring  patterns  can  be  analyzed  once  all  performer  and  supporting  alternatives 
are  complete  providing  the  designer  insight  into  the  interdependence  of  the  relationships 
(Johnson,  2014).  Figure  9  summarizes  the  different  color  combinations  and  what  the 
corresponding  color  combinations  represent. 
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Figure  9.  Potential  Interdependence  Analysis  Table  Color  Combinations 
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Source:  Johnson,  M.  (2014j.  Coactive  design:  Designing  support  for  interdependence  in 
human-robot  teamwork.  Doctoral  dissertation.  Delft  University  of  Technology- 
Mekelweg/Netherlands. 


The  following  quote  from  Johnson  (2014)  illustrates  the  importance  in 
understanding  the  color  combinations: 

Overall,  the  colors  in  the  first  column  provide  an  understanding  of  how  the 
performer  would  fare  if  required  to  meet  the  capacity  requirement 
autonomously.  Colors  other  than  green  in  the  performer  column  indicate 
some  limitation  of  performer,  such  as  potential  brittleness  due  to  reliability 
(yellow),  hard  interdependency  due  to  lack  of  capacity  (orange),  or  just  a 
complete  lack  of  capacity  (red). 

The  supporting  team  member  columns  provide  an  understanding  of  what 
type  of  interdependence  relationships  could  potentially  be  supported.  The 
color  red  in  these  columns  indicates  that  there  is  no  chance  for  assistance. 

This  makes  the  performer  a  single  point  of  failure.  If  the  performer  is  less 
than  100  percent  reliable,  you  will  have  a  brittle  system.  However,  if  you 
can  provide  support  for  interdependence  then  you  can  avoid  the  single 
point  of  failure.  Colors  other  than  red  in  the  supporting  team  member 
column  indicate  potential  required  (orange)  or  opportunistic  (yellow  and 
green)  interdependence  relationships  between  team  members.  The  hard 
interdependencies  are  usually  easy  to  identify  because  you  cannot 
complete  the  task  without  it.  Soft  interdependencies  tend  to  be  more 


27 


subtle,  but  provide  valuable  opportunities  for  teamwork  and  alternative 
pathways  to  a  solution.  (2014,  pg.77) 

It  is  thanks  to  this  relatively  simple  set  of  color  combinations  that  repeatable 
patters  in  behaviors  and  support  relationships  are  made  easily  identifiable.  As  a  result, 
Johnson  (2014)  stated  that  it  becomes  increasingly  simple  to  identify  the  following: 

•  Agents  lacking  capacity  and  those  that  can  offer  it 

•  Agents  lacking  100  percent  reliability  and  those  that  can  supplement  it 

•  Capacity  overlaps  that  provide  opportunistic  relationships 

Johnson  (2014)  stated  that  the  OPD  requirements  derive  from  these  interpretations 
and  answer  the  questions: 

•  Who  needs  to  observe  what,  from  whom? 

•  Who  needs  to  be  able  to  predict  what? 

•  How  do  members  need  to  be  able  to  direct  each  other? 

After  these  requirements  have  been  identified,  a  system’s  designer  will  possess  a 
set  of  interdependent  relationships  that  must  be  supported  by  the  system  and  the 
requirements  that  make  those  relationships  possible.  This  completes  the  identification 
process,  the  first  of  three  processes,  within  Figure  6,  the  Coactive  Design  Method.  The 
remaining  two  processes,  the  selection  and  implementation  process  and  the  evaluation  of 
change  process,  keep  to  their  respective  name  sakes  and  require  little  explanation.  The 
selection  and  implementation  process  involves  finding  design  mechanisms  capable  of 
meeting  the  requirements  obtained  in  the  identification  process  and  implementing  them. 
The  evaluation  of  change  process  consists  of  ensuring  the  mechanisms  chosen  to  support 
the  requirements  adequately  meet  expectations  and  that  no  secondary  effects  on  other 
OPD  relationships  have  resulted  from  their  implementation.  These  feedback  loops,  as 
indicated  in  Figure  6,  lend  themselves  to  an  iterative,  spiral  design  process  as  described 
by  Satzinger,  et  al.  (2012).  If  other  OPD  relationships  are  affected  or  if  additional  tasks  or 
capabilities  are  identified  they  need  to  be  inserted  into  the  identification  process  and  the 
Coactive  Design  Method  rerun.  Once  all  possible  solutions  have  undergone  and  passed 
their  performance  and  human  integration  tests  the  system  will  be  ready  for  deployment. 
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H.  CHAPTER  CONCLUSION  AND  SUMMARY 


This  chapter  began  with  the  UTACC  vision  and  overview  and  stated  the  need  for 
continuing  the  exploratory  initiative,  expressed  in  EF21.  There  were  two  major  bodies  of 
work  analyzed  and  merged  together  under  this  thesis’  research.  The  first  body  of  work 
was  Rice’s  et  al.  (2015)  UTACC  Concept  of  Operations  which  possesses  the  Mission 
Execution  and  Planning  Model  and  the  Task  Analysis  Worksheets.  The  second  effort 
analyzed  during  this  research  was  Johnson’s  (2014)  Coactive  Design  Method,  including 
an  iterative  Coactive  Design  Model  and  the  Interdependence  Analysis  Tables. 
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III.  RESEARCH  METHODOLOGY 


In  2013,  the  Marine  Corps  Warfighting  Laboratory  (MCWL)  began  exploring  the 
Unmanned  Tactical  Autonomous  Control  and  Collaboration  (UTACC)  initiative.  Rice  et 
al.  (2015)  and  Batson  and  Wimmer  (2015)  pioneered  the  early  development  of  the 
UTACC  concept  and  validated  the  concept’s  viability  by  providing  initial  concept 
designs  and  threat  and  vulnerability  assessments.  In  the  short  term,  these  results  meant 
the  continuation  of  the  program  and  the  exploration  of  capturing  what  were  traditionally 
human  to  human  interactions  and  the  translation  of  these  interactions  when  a  machine  is 
substituted  into  the  equation.  The  successful  achievement  of  this  end  state  sets  the 
conditions  for  the  final,  long  term  configuration  of  UTACC,  laid  out  as  a  “decision¬ 
centric,  semi-autonomous,  distributive,  multi-agent,  multi-domain  robotic  system” 
(SOW,  2014). 

With  this  configuration  in  mind  for  the  foundation  of  UTACC,  the  next  step 
forward  was  to  determine  the  special  information  exchange  requirements  between 
Marines  and  machines  that  ought  to  be  implemented  into  the  UTACC  system.  Coactive 
design  was  chosen  as  the  method  for  documenting  these  exchanges,  since  research 
indicated  that  it  was  the  only  systems  engineering  process  available  that  enabled 
requirements  generation  for  robot-Marine  teaming.  This  thesis  looked  at  the  feasibility  of 
incorporating  coactive  design  as  a  repeatable  process  within  the  UTACC  Enterprise 
Engine.  To  accomplish  the  incorporation  of  Coactive  Design,  the  lead  architect  of  the 
original  Coactive  Design  Method,  Dr.  Matthew  Johnson,  was  sought  out  to  teach  this 
author  how  to  apply  the  method  to  the  UTACC  initiative.  The  author  conducted  two 
separate  trips  to  the  Institute  of  Human  Machine  Cognition  (IHMC)  where  Johnson 
continues  his  work  with  Coactive  Design.  The  first  trip  sought  to  educate  the  author  on 
the  process  and  the  second  trip  validated  the  application  of  this  knowledge  to  UTACC. 

A.  DEFINITION  OF  THE  PROBLEM 

The  Rice  et  al.  (2015)  Mission  Planning  and  Execution  Model  and  Task  Analysis 
Worksheets  were  well  suited  to  the  initial  proof  of  concept.  However,  there  are  a  number 
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of  reasons  why  the  Rice  et  al.  (2015)  model,  as  a  standalone,  should  not  be  used  by 
UTACC  system  designers  for  future  consideration.  The  work  of  Rice  et  al.  (2015)  was 
limited  in  scope  as  it  only  analyzed  the  reconnaissance  mission  and  not  indicative  of 
reconnaissance  missions  in  general.  The  UTACC  system  is  envisioned  to  be  adaptive  to  a 
wide  range  of  dynamically  changing  missions. 

The  Mission  Planning  and  Execution  Model  also  failed  to  record  the  level  of 
interaction  between  agents  necessary  to  complete  tasks  within  a  larger  mission  set. 
Without  this  information  the  reliance  on  specific  environmental  conditions  being  met 
before  work  can  be  accomplished  is  high.  It  is  the  identification  of  perceptual,  cognitive, 
and  physical  needs  that  provides  insight  into  what  interdependencies  are  at  play  and 
which  agents  are  best  suited  to  perform  and  support  tasks.  The  interdependent  framework 
of  the  Coactive  Design  Model  and  the  Interdependence  Analysis  Tables  provide  the  level 
of  responsiveness  that  a  system  like  UTACC  needs  to  be  built  around.  An  agile  and 
system  conscious  design  method  like  coactive  design  is  more  efficient  in  both  the  short 
and  long  term;  Coactive  Design’s  main  selling  point  is  that  it  delivers  design  mechanisms 
to  developers  that  more  accurately  capture  the  system  as  a  whole. 

At  the  time  of  this  writing  a  second  round  of  UTACC  demonstrations  has  been 
planned.  The  goal  of  the  demonstrations  is  to  exhibit  a  few  new  features  of  the  systems 
but  the  context  of  a  controlled  reconnaissance  mission  remains  the  same.  The  existing 
work  of  Rice  et  al.  (2015),  specifically  the  Mission  Planning  and  Execution  Model, 
became  a  natural  starting  place  for  this  research.  The  author  attempted  to  incorporate  as 
much  of  that  work  into  the  Coactive  Design  Model  as  possible.  The  successful  merger  of 
these  two  models  would  aid  in  the  increased  dissemination  and  acceptance  of  the  new 
model  with  respect  to  those  involved  with  the  UTACC  initiative  and  the  prospective  user 
community.  This  preservation  of  the  existing  UTACC  knowledge  base  would  send  a 
message  more  in  line  with  a  software  upgrade  rather  than  an  operating  system  switch,  and 
this  would  result  in  being  viewed  as  only  minimally  invasive  to  MCWL. 
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B.  MODIFYING  COACTIVE  DESIGN  PROCESSES  FOR  UTACC 


During  the  first  trip  to  IHMC,  the  author  gained  insight  into  how  the  Coactive 
Design  Method  operated  within  the  context  of  IHMC’s  unique  operating  environment. 
That  body  of  knowledge  is  summarized  in  the  Chapter  Two  literature  review.  While 
many  similarities  exist  between  IHMC’s  work  and  that  which  UTACC  aims  to  achieve, 
the  UTACC  operating  environment  presents  many  unique  challenges  that  were  not 
relevant  to  IHMC. 

I.  UTACC  Interdependence  Analysis  Table 

As  an  illustration  of  this  point,  the  IHMC  construct  revolved  around  a  single 
humanoid  robot,  whereas  the  UTACC  initiative  seeks  a  multi-domain,  multi-agent 
system.  Despite  these  differences,  the  Coactive  Design  Method  as  proposed  by  Johnson 
(2014),  and  illustrated  in  Figure  6,  remained  unaltered.  However,  the  analysis  tool 
utilized  to  accomplish  this  method  had  to  be  tailored  accordingly.  The  modified  UTACC 
Interdependence  Analysis  (lA)  Table  with  cell  descriptions  is  listed  in  Figure  10. 


Figure  10.  UTACC  Interdependence  Analysis  Table 
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Adapted  From:  Johnson,  M.  (2014).  Coactive  design:  Designing  support  for 
interdependence  in  human-robot  teamwork.  Doctoral  dissertation,  Delft  University  of 
Technology-  Mekelweg/Netherlands. 
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The  UTACC  Interdependence  Analysis  Table  also  reflects  the  desire  to  maintain 
as  much  of  the  pre-existing  concept  design  from  the  Rice  et  al.  (2015)  thesis  work  as 
possible.  Incorporating  the  essentials  of  the  Mission  Planning  and  Execution  Model 
developed  by  Rice  et  al.  (2015),  required  several  modifications  to  the  original  lA  Table  as 
developed  by  Johnson  (2014).  An  additional  column  was  added  to  the  front  of  the  table 
which  groups  tasks  within  the  Marine  Corps  Troop  Leading  Steps.  Alternative  teaming 
roles  were  expanded  to  allow  for  multi-domain,  multi-robotic  agents,  including  the 
potential  for  the  human  to  serve  as  the  performer  with  the  robotic  elements  serving  in  the 
support  roles.  The  most  developed  UTACC  use  case  allows  for  multiple  air  and  multiple 
ground  robots,  as  well  as,  multiple  humans.  However,  this  work  distilled  the  UTACC  use 
case  down  into  a  single  unmanned  ground  system  (UGS),  unmanned  air  system  (UAS), 
and  human  element.  The  three  different  teaming  role  alternatives  are  then  a  rotation  of 
performer  among  the  three  agents  while  the  remaining  agents  serve  in  support  roles. 

2.  UTACC  Color  Scheme 

When  the  lA  table  was  modified  to  meet  the  needs  of  the  UTACC  initiative,  the 
author  noticed  an  expanding  level  of  complexity,  corresponding  to  the  need  to  analyze 
three  teaming  role  alternatives  as  opposed  to  two  in  the  Johnson  (2014)  work.  By 
eliminating  many  of  the  possibilities  that  were  inherently  not  feasible,  the  author  could 
more  easily  sift  through  numerous  possibilities  of  interdependent  relationships  and 
interpret  more  accurately  what  the  color  combinations  represented.  Figure  1 1  depicts  the 
modified  UTACC  lA  Color  Scheme. 
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Figure  11.  UTACC  Interdependence  Analysis  Color  Scheme 
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Adapted  from:  Johnson,  M.  (2014).  Coactive  design:  Designing  support  for 
interdependence  in  human-robot  teamwork.  Doctoral  dissertation,  Delft  University  of 
Technology-  Mekelweg/Netherlands. 


The  color  gray  added  to  the  Interdependence  Analysis  Color  Scheme  makes  it 
easier  to  analyze  interdependent  teaming  role  alternatives.  Simply,  the  color  gray 
represents  the  agent  is  not  in  the  role  of  the  performer  or  the  supporting  team  member  and 
is  not  applicable  for  consideration.  An  example  of  when  this  color  simplifies  analysis  of 
teaming  role  alternatives  follows.  Figure  12  helps  illustrate  the  example. 


Figure  12.  Example  UTACC  lA  Color  Scheme 


The  example  explains  how  the  author  applied  the  color  scheme  to  the  capacity  of 
resolving  airspace.  In  this  case,  the  UAS  must  be  the  performer.  So  the  alternatives  where 
the  human  and  UGS  are  the  performer,  the  alternates  would  be  completely  gray  and  thus 
eliminate  the  need  to  analyze  them  later  in  the  Coactive  Design  Method.  Also,  as  the 
UGS  is  restricted  to  the  ground,  it  would  be  unable  to  help  the  UAS  resolve  airspace  and 
therefore  would  be  shaded  gray  under  the  supporting  team  member  column.  This  would 
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leave  only  the  human  in  the  role  of  supporting  the  UAS  as  lacking  a  color.  In  this 
manner,  eliminating  seven  out  of  nine  relationships  with  regard  to  one  capacity  greatly 
reduces  the  complexity  of  the  resulting  color  schemes  and  allows  the  coactive  designer  to 
focus  their  attention  on  this  one  interdependent  relationship. 

C.  CHAPTER  SUMMARY 

This  chapter  began  by  outlining  the  issues  with  the  old  Mission  Planning  and 
Execution  Model,  as  developed  by  Rice  et  al.  (2015).  Coactive  Design  was  selected  to 
resolve  these  issues  and  serve  as  the  system’s  development  method  for  the  duration  of  the 
UTACC  program.  Coactive  Design  required  slight  process  modifications  in  order  to 
seamlessly  fuse  UTACC  concepts.  Among  the  most  significant  modifications  were  the 
minor  alterations  made  to  the  lA  Tables  framework  and  the  additional  category  added  to 
the  lA  Color  Scheme.  An  example  was  provided  to  illustrate  how  these  modifications 
accommodated  the  UTACC  construct  by  simplifying  analysis,  despite  UTACC 
possessing  a  larger  framework  than  Coactive  Design  was  originally  designed  to  handle. 
The  next  chapter  will  explore  the  results  of  applying  the  Coactive  Design  method  to 
UTACC. 
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IV.  UTACC  COACTIVE  DESIGN  RESULTS 


This  section  delivers  an  executive  overview  of  the  results  from  applying  Coactive 
Design  to  Unmanned  Tactical  Autonomous  Control  and  Collaboration  (UTACC).  This 
executive  summary  will  focus  on  major  components  of  the  Interdependence  Analysis 
(lA)  Tables,  many  of  which  were  supported  by  the  Task  Analysis  Worksheets  of  Rice’s 
et  al.  (2015)  work. 

The  work  flow  analyzed  by  the  UTACC  Coactive  Design  was  modeled  off  of  the 
Marine  Corps  Troop  Leading  Steps,  a  work  break  down  structure  organic  to  the  Marine 
Corps  that  forms  the  basis  of  mission  planning.  The  steps  of  this  structure  spell  out  the 
acronym  BAMCIS  and  consist  of:  Begin  the  Planning,  Arrange  for  Reconnaissance, 
Make  Reconnaissance,  Complete  the  Plan,  Issue  the  Order,  and  Supervise  Activities.  An 
lA  Table  was  developed  for  each  of  these  steps. 

Due  to  the  size  of  the  lA  Tables,  they  had  to  be  partitioned  off  to  allow  for 
discussion  in  this  format.  Depending  on  the  number  of  tasks  within  each  BAMCIS  step,  a 
particular  lA  Table  may  be  split  into  many  sections.  These  partitions  also  serve  the 
purpose  of  incrementally  stepping  through  the  way  the  lA  Tables  were  created.  This 
presentation  style  will  assist  any  follow  on  Coactive  Designer  in  understanding  the 
author’s  train  of  thought,  which  was  heavily  influenced  by  his  infantry  experience.  All  of 
the  resultant  lA  Tables’  tasks  are  stacked,  decomposed  and  analyzed  within  the 
alternative  teaming  options  and  possess  observability,  predictability,  and  directability 
(OPD)  requirements.  This  chapter  will  present  the  lA  Tables  with  a  discussion  of  the 
OPD  requirements  and  key  takeaways  for  developers. 

A.  BEGIN  PLANNING  lA  TABLES 

The  first  phase  of  the  Troop  Leading  Steps  work  flow  is  the  B  in  BAMIS:  begin 
planning.  The  tasks  associated  with  UTACC  in  this  phase  involve  initiating  the  system 
and  setting  preferences  and  then  entering  mission  parameters  based  on  a  directive 
received  from  a  higher  level  command,  thus  initiating  a  mission. 
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1.  Begin  Planning:  Initiate  System  and  Set  Preferences 

Initiating  the  system  and  setting  preferences  involves  the  subtask  of  setting  the 
desired  level  of  autonomy.  This  subtask  is  broken  down  into  defining  the  general  nature 
of  each  human-machine  relationship  and  having  the  system  understand  its  role  within 
each  different  level.  Figure  13  depicts  this  task  decomposition  and  provides  the  OPD 
requirements  for  achieving  it. 


Figure  13.  Begin  Planning  lA  Table:  Initiate  System  and  Set  Preferences 
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The  OPD  requirements  drawn  from  this  lA  Table  are  concerned  with  calibrating 
the  system,  identifying  all  participating  teammates,  and  establishing  the  desired  level  of 
autonomy  that  is  initially  required  of  the  system.  Coordinating  instructions  for  events  that 
concern  contingencies  (e.g.,  loss  of  communication  with  the  robots,  and  necessity  to 
adjust  the  level  of  autonomy  mid-mission)  are  listed  as  well.  The  process  of  facilitating 
the  interface  design  is  also  mentioned  in  the  table. 

2.  Begin  Planning:  Enter  Mission  Parameters 

The  mission  parameters  have  been  delineated  in  a  format  that  all  Marines  are 
familiar  with,  known  as  the  Five  Paragraph  Order  (5PO).  OSMEAC  is  the  acronym  used 
to  teach  the  5PO  and  stands  for  Orientation,  Situation,  Mission,  Execution, 
Administration  and  Eogistics,  and  Command  and  Signal.  Each  has  been  assigned  as  a 
subtask  and  is  further  broken  down  within  the  capacity  field  of  the  lA  Tables. 

The  Marine  unit  leader  must  receive  the  tasking  directive  and  relay  it  to  his  unit 
before  setting  them  in  motion.  As  UTACC  is  now  a  member  of  the  unit,  that  unit  leader 
must  now  relay  the  directive  to  it  as  well.  It  is  perceived  that  entering  these  parameters 
will  benefit  the  unit  leader’s  understanding  of  the  mission  and  better  facilitate  the 
translation  of  the  mission  to  the  human  teammates,  as  well. 

a.  Five  Paragraph  Order:  Orientation  and  Situation 

While  the  orientation  is  not  one  of  the  essential  five  paragraphs  within  the  5PO,  it 
is  necessary  for  properly  framing  the  mission.  With  regard  to  UTACC,  that  translates  into 
ensuring  the  system  understands  the  operating  area.  An  effective  orientation  sets  the  stage 
for  the  situation  which  has  an  enemy  and  a  friendly  component.  Eigure  14  depicts  the  O 
and  S  portions  of  this  task  decomposition  and  provides  the  OPD  requirements  for 
achieving  it. 
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Figure  14.  Begin  Planning  lA  Table:  the  OSMEAC  “O”  and  “S” 
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The  OPD  requirements  associated  with  achieving  the  O  and  S  are  concerned  with 
input  fields  on  the  user  interface.  The  Marine  must  provide  this  information  in  order  to 
convey  where  the  system  will  be  operating,  if  friendly  forces  or  the  effects  of  friendly 
forces  will  be  experienced,  and  whether  or  not  to  anticipate  resistance  from  perceived 
threats. 


b.  Five  Paragraph  Order:  Mission 

The  mission  paragraph  is  where  the  overall  mission  of  the  team  is  described —  not 
to  be  confused  with  the  individual  assignments  of  the  team  members,  which  are  referred 
to  as  tasking  statements  and  follow  later  in  the  5PO.  Also  of  note,  a  tactical  task  is  the 
term  for  the  action  to  be  conducted  during  a  mission.  All  mission  statements  and  tasking 
statements  must  contain  one,  and  only  one,  tactical  task.  A  list  of  published  tactical  tasks 
with  clear  definitions  that  permit  Marines  the  ability  to  quickly  communicate  desired 
actions  and  outcomes  can  be  found  in  Marine  Corps  doctrinal  publications  like  MCRP  5- 
12a:  Operational  Terms  and  Graphics.  New  tactical  tasks  may  need  to  be  developed  as 
systems  find  their  way  onto  the  battlefield.  Such  discussion  is  beyond  the  scope  of  this 
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thesis.  Understanding  the  mission  of  the  system  within  the  related  mission  of  the  team  is 
the  capaeity  deseribed  in  Figure  15. 


Figure  15.  Begin  Planning  lA  Table:  the  OSMEAC  “M” 
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drives  toward  a  specific  end  state.  May  need 
to  derive  new  tactical  tasks  for  rotwt  missions 
(ie.  Conduct  a  Route  Recon  or  Zone  or  Area 
Recon).  Provide  a  list  of  current  tactical  tasks 
as  an  appendix.  UTACC  should  understand 


The  OPD  requirements  listed  in  Figure  15  describe  a  list  of  input  fields  needed  on 

the  user  interface  that  will  shape  how  and  what  tasks  the  systems  will  perform.  The 

additional  details  will  help  ensure  that  the  system’s  actions  (which  will  be  specified  in  the 

tasking  statements)  are  nested  within  the  team’s  mission. 
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c.  Five  Paragraph  Order:  Execution 

The  next  paragraph  of  the  5P0  is  Execution  and  revolves  around  the  physical 
actions,  setting  conditions,  and  sequencing  of  events.  In  order  to  convey  this  information, 
the  paragraph  is  broken  down  into  several  subparagraphs:  the  Commander’s  Intent  within 
the  Concept  of  Operations  (CONOPS),  the  Scheme  of  Maneuver  (SOM)  within  the 
CONOPS,  the  Fire  Support  Plan  (ESP)  within  CONOPS,  Tasking  Statements,  and 
Coordinating  Instructions.  Figure  16  depicts  this  breakdown  and  the  OPD  requirements 
necessary  to  achieve  them.  Further,  this  establishes  the  shared  objective  between  Marines 
and  machines. 
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Figure  16.  Begin  Planning  lA  Table:  the  OSMEAC  “E” 
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Many  of  the  perceived  benefits  of  including  all  of  the  elements  of  the  5PO  into 
this  lA  Table  relate  back  to  the  influence  they  have  over  the  thought  processes  of  the  unit 
leader.  While  a  particular  element  may  or  may  not  directly  impact  the  actions  of  a  team 
member  (whether  Marine  or  machine),  they  remain  a  part  of  the  planning  process  for  the 
role  they  play  in  the  larger  picture.  Within  the  execution  paragraph  it  becomes  easy  to 
develop  tunnel  vision  and  hone  in  on  tasks;  that  is,  after  all,  what  the  unit  leader  will  be 
ordering  the  systems  and  Marines  to  go  out  and  accomplish.  It  is  the  other  elements  of 
this  paragraph  that  tie  the  otherwise  disjointed  tasks  together.  The  OPD  requirements 
described  in  Figure  16  help  guide  the  design  of  the  interface  to  quickly  guide  the  user 
through  developing  their  plan. 

d.  Five  Paragraph  Order:  Admin  /  Logistics  and  Command  /  Signal 

The  final  two  paragraphs  of  the  5PO  are  the  administration  and  logistics  plan  and 
the  command  and  signal  plan.  True  to  their  names,  these  paragraphs  deal  with  personnel 
and  robot  accountability,  resupply  and  refueling,  communication  architectures,  and 
succession  of  authority  or  command  relationships.  The  capacities  listed  in  Figure  17 
detail  these  points  and  provide  the  OPD  requirements  necessary  to  achieve  them. 
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Figure  17.  Begin  Planning  lA  Table:  the  OSMEAC  “A”  and  “C” 
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The  OPD  requirements  listed  in  Figure  17  focus  more  on  system  requirements 
than  on  interface  design.  The  fields  of  information  are  of  use  to  the  system  in  identifying 
and  tracking  friendly  units;  understanding  where  to  go  and  what  to  do  when 
electronically  cut  off  from  the  team;  prioritize  who  to  take  commands  from;  and  when 
and  how  long  to  communicate.  These  two  final  paragraphs,  the  “A”  and  “C”  paragraphs 
of  the  5PO,  complete  the  Begin  Planning  phase  of  the  BAMCIS  work  flow. 

B.  ARRANGE  RECONNAISSANCE  lA  TABLES 

The  second  phase  of  the  Troop  Leading  Steps  work  flow  is  the  A  in  BAMCIS, 
arrange  reconnaissance.  The  tasks  associated  with  UTACC  in  this  phase  involve 
conducting  initial  mapping  in  order  to  orient  the  team  to  the  area  of  operations  and 
selecting  emphasis  areas. 

1.  Arrange  Reconnaissance:  Conduct  Initial  Mapping  to  Orient 

Conducting  initial  mapping  to  orient  involves  the  following  subtasks:  depart 
friendly  lines;  scan  area  between  origin  and  objective  for  geographic  features;  scan 
objective  area  for  basic  geography;  build  a  map;  notify  when  near  the  completion  of 
mapping;  monitor  system  health;  review  initial  map  highlight  areas  for  further 
refinement;  and  query  external  joint  assets.  Due  to  the  size  of  the  Arrange  for 
Reconnaissance  lA  Table,  it  was  broken  down  into  four  smaller  lA  tables  for  the  ease  of 
presenting  it  in  this  thesis. 

a.  Initial  Mapping:  Depart  and  Scan  between  Origin  and  Objective 

Figure  18  depicts  the  task  decomposition  for  the  first  two  of  six  subtasks  under 
the  task  for  conduct  initial  mapping  to  orient;  it  also  provides  the  OPD  requirements  for 
achieving  them. 
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Figure  18.  Arrange  Reeonnaissanee:  Initial  Mapping:  Depart  and  Sean 
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Fly  Areas  for  restricted  ar  space  These  normal  altitude 
parameters  should  be  default  set  and  used  m  the  design  of 
lenses  and  imagine  devices  but  should  allow  for  field 
mocWcations,  especially  the  NFAs  Examples  of  NF As 
include  active  landing  zones  and  drop  zones,  holding  areas 
for  helicopters,  and  other  ar  control  measures  where  arcraft 
are  designated  to  operate  in  The  ability  for  miitary  ar  craft  to 
share  the  same  arspace  would  require  ability  for  drone  to 
detect  manned  (and  unmanned  arcraft)  and  deconflict  in  an 
EM  contested  environment  Also,  should  be  able  to  tap  into 
gun  target  lines  and  surface  danger  zones  todeconflict| 
altitude  with  artillery  and  mortar  traiectones  This  can  be 
accomplished  by  drone  ability  to  remotely  access  command 
battle  tracking  systems .( initial  map  is  a  geographic  map  that 
IS  captured  by  the  UAS  only  .) 


the  human  must  determine  and  communicate  the  size 
(overlap  of  scans)and  locabon  of  the  area  to  be  scanned  the 
human  can  streamline  efficiency  and  timeliness  of  the  system 
by  constraning  the  initial  mapping  of  the  area  This  requires 
an  interface  that  allows  the  human  to  input  military  gnds 
(MGRS)  A  scaled  gnd  square  of  varying  dimensions  can 
then  by  applied  to  a  military  map  projection  display  for  the 
human  to  ’shave  off  unnecessary  scan  areas  '  it  wi  also  be 
necessary  for  the  human  to  identify  starting  point  through  use 
of  gnds  and  or  other  points  of  interest  through  gnds  or 
highlighting  on  the  display.  It  may  also  be  possible  that  no 
additional  information  is  avalable  outside  of  starting  gnd  and 
objective  gnd  and  that  the  human  operator  would  need  to 
determine  only  size  of  box  to  scan,  (point  clouds  vs  three 
model  vs  overhead  imagery) 


•Jie  JASwir  be  able  to  plan  i*'s  route  for  scanning  to  meet 
the  objects  defined  above  The  human  may  be  able  to  help 
focus.'  narrow  down  the  area  By  using  intuition  totnm  the 
map  down  or  use  of  joint  assets  to  trim  with  the  above 
mission  parameters  defined  for  the  scan  the  robot  should 
determine  how  to  efficiently  map  the  area  This  wi  take  into 
account  overlapping  scan  patterns  so  that  it  can  correlate 
data  from  one  scan  to  data  in  the  next  (line  up  the  images), 
registration  issue,  (use  of  map  is  for  cofliskm  avoidance 
What  has  been  searched  and  found  and  what  hasn't?  Who  is 
using  It  and  why?  If  robots,  then  what  format  and  is  it  useful 
for  them?  If  for  the  human ,  same  question? 


The  OPD  requirements  for  the  resolving  airspace  capacity  involve  free  and  safe 
flight  of  the  UAS  from  takeoff  to  landing.  The  OPD  requirements  associated  with 
understanding  the  size  of  the  area  to  scan  between  origin  and  objective  established  a  box 
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shaped  operating  area  for  the  UAS  with  the  origin  in  one  corner  and  the  objective  in  the 
comer  diagonally  opposite.  The  OPD  requirements  for  the  task,  plan  how  to  scan  the 
area,  identify  information  that  the  system  must  provide  to  the  Marines. 

Figure  18  offers  the  first  glimpse  of  true  interdependence  at  work  during  the 
BAMCIS  process.  The  pattern  of  colors  that  emerges  from  Figure  18  indicates  that  the 
Marine  and  machine  are  communicating  with  one  another  and  are  relying  on  one  another 
to  do  some  element  of  work  that  the  other  is  incapable  of  conducting.  The  first  row 
within  Figure  18  shows  that  the  UAS  is  capable  of  carrying  out  the  given  capacity.  The 
second  row  depicts  a  hard  constraint,  i.e.,  a  hard  interdependence,  where  the  human  is 
required  to  perform  a  function.  The  third  row  shows  that  the  UAS  is  capable  of  carrying 
on  with  planning  after  receiving  human  input.  The  OPD  requirements  for  this  row 
provide  the  Marine  a  visual  aid  to  understand  what  the  UAS  scan  path  and  time  of  flight 
will  look  like,  based  off  how  that  Marine  shapes  the  scan  area  (the  information  exchange 
from  the  second  row  of  Figure  18). 

Figure  18  offers  insight  regarding  where  UTACC  should  spend  time  and 
resources  during  the  development  cycle  and  where  it  should  not.  The  hard 
interdependencies  of  row  two  in  Figure  18  should  be  avoided  from  an  automation 
perspective.  The  Marines  have  the  ability  to  quickly  and  effortlessly  provide  a  capability 
that  the  system  is  incapable  of  mastering,  rather  than  getting  bogged  down  trying  to 
marginally  provide  an  automated  capability  that  the  Marine  is  available  for  and  would 
prefer  to  have  control  of  in  the  first  place.  Development  should,  however,  focus  on  rows 
one  and  three  of  Figure  18.  The  issues  with  rows  one  and  three  can  be  fixed  during 
development.  These  issues  lie  in  the  translation  of  the  [already  present]  information  that 
is  necessary  for  Marines  and  machines  to  make  their  decisions.  The  human  must 
determine  and  prioritize  what  is  important  to  scan.  That  ability  is  greatly  enhanced  if  the 
system  can  visually  display  a  correlated  time  of  flight  and  scan  path  as  the  Marine  plays 
with  the  parameters  of  the  scan  box.  These  requirements  introduce  opportunities  for  the 
Marines  and  robots  to  share  information  for  the  first  time  during  the  BAMCIS  process. 
This  theme  will  emerge  several  times  over  throughout  the  remainder  of  the  lA  Tables’ 
analysis. 
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b.  Initial  Mapping:  Scan  Objective  and  Build  Map 

The  second  set  of  subtasks  under  the  task  of  conduct  initial  mapping  to  orient  are: 
scan  objective  area  for  basic  geography  and  build  the  map.  Each  subtask  has  multiple 
capacities:  execute  initial  mapping  protocol;  generating  actionable  information; 
transmitting  map  information;  identifying  between  urban  and  wooded  areas;  and 
identifying  masked  areas.  The  OPD  requirements  for  these  capacities  are  shown  in  Figure 
19. 


Figure  19.  Arrange  Reconnaissance:  Initial  Mapping:  Scan  Objective  and 
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The  OPD  requirements  for  Figure  19  are  centered  on  improving  the  UAS  in  the 
performance  of  its  duties  and  not  in  translating  information  from  Marine  to  machine  or 
vice  versa.  These  requirements  aim  to  improve  sensor  quality  and  processing  on  board 
the  system  and  are  only  limited  to  the  scope  of  current  technology.  This  is  much  simpler 
to  address  compared  with  translating  information  exchanges  between  Marines  and 
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machines.  Similar  to  the  Begin  Planning  lA  Tables,  where  the  human  was  doing  the 
majority  of  the  work,  here  the  UAS  is  required  to  take  on  the  lion’s  share  of  the  work. 

c.  Initial  Mapping:  Notify  when  Complete  and  Monitor  System  Health 

The  final  two  subtasks  of  the  task  conduct  initial  mapping  to  orient  are:  notify 
when  near  eompletion  of  mapping  and  monitor  system  health.  Each  has  one  capacity  and 
the  OPD  requirements  associated  with  achieving  them  are  listed  in  Figure  20. 


Figure  20.  Arrange  Reconnaissance:  Initial  Mapping:  Notify  when  Complete 
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The  OPD  requirements  for  Figure  20  follow  a  similar  trend  to  Figure  19.  Their 
aim  is  to  enhance  the  UAS  in  sensing  and  processing.  A  few  minor  interface  designs  are 
suggested  to  keep  the  Marines  cognizant  of  the  UAS’  status  while  conducting  the  initial 
mapping. 

2.  Arrange  Reconnaissance:  Select  Emphasis  Area(s) 

The  Arrange  Reconnaissance  lA  Table’s  final  task  is  select  emphasis  area(s).  It  is 
broken  down  into  two  subtasks:  review  initial  map  highlight  areas  for  further  refinement 
and  query  external  /  joint  assets.  The  former  subtask  has  one  capacity  and  the  latter  has 
two.  Figure  21  depicts  these  and  the  OPD  requirements. 
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Figure  21.  Arrange  Reconnaissanee:  Select  Emphasis  Area(s) 

I  Option  1  I  OptKin  2  |  Option  3  | _ 
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The  OPD  requirements  in  Figure  21  shift  back  to  a  Marine  focus.  This  handoff 
from  machine  to  Marine  demonstrates  that  the  machine  has  satisfied  the  Marine’s 
immediate  need  for  information  and  is  allowing  the  Marine  to  process  that  information. 
This  task  completes  the  Arrange  Reconnaissance  lA  Table  and  the  second  step  in 
BAMCIS. 

C.  MAKE  RECONNAISSANCE  lA  TABLES 

The  third  phase  of  the  Troop  Leading  Steps  work  flow  is  the  M  in  BAMIS:  make 
reconnaissance.  The  tasks  associated  with  UTACC  in  this  phase  involve  conducting 
detailed  mapping,  and  creating  the  modified  combined  obstacle  overlay  (MCOO).  The 
make  reconnaissance  phase  is  partitioned  into  two  separate  lA  Tables. 
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1.  Make  Reconnaissance:  Return,  Scan,  Alert,  Notify,  and  Monitor 

The  first  task  of  the  Make  Reconnaissance  lA  Table,  conduct  detailed  mapping,  is 
broken  down  into  five  subtasks:  return  to  selected  emphasis  area(s);  scan  selected 
emphasis  area(s);  alert  team  to  relevant  map  information;  notify  team  when  near 
completion  of  mapping;  and  monitor  system  health.  Figure  22  depicts  each  subtask,  its 
capacities,  and  associated  OPD  requirements. 


Figure  22.  Make  Reconnaissance:  Return,  Scan,  Alert,  Notify,  and  Monitor 
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Due  to  the  similarities  in  the  two  tasks,  the  OPD  requirements  in  Figure  22  are 
similar  to  those  under  conduct  initial  mapping.  However,  the  completion  of  the  detailed 
mapping  is  necessary  for  the  output  of  the  next  task,  which  is  a  critical  planning  factor  for 
missions. 
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2.  Make  Reconnaissance:  MCOO 

The  second  task  of  the  Make  Reconnaissance  lA  Table  is  the  generation  of  a 
MCOO.  MCOOs  are  broken  down  into  specific  overlays,  the  generation  of  which 
specifies  the  subtasks  of  this  task:  vegetation;  surface  drainage;  other  effects;  combined 
obstacles;  mobility  corridors;  and  avenue  of  approach.  Sub-overlays  can  often  be  broken 
down  further  into  specific  features,  each  of  which  constitutes  a  single  capacity.  This 
breakdown  and  the  corresponding  OPD  requirements  are  shown  in  Figure  23. 


Figure  23.  Make  Reconnaissance:  MCOO 


D«K!Typeof 

Vegaaijon 


DepK!  '_>«  spacing,  OjameEf,  so. 
types,  and  conditons  thataflectmoMy. 


Depict 

Surface 

Dratiage 


Depict  Water 
Sources 


DeP'Ci  Surface 

Conligyratiofi 


Depict  Ail 
Other  Effects 


Depict 

Obstacles 


Transportation 

Systems 


Depict  Sevei^ 
Restricted 
Terran 


MCOO 

[modified 

combined 

obstacle 

overlay) 


Depict 

Combined 

Obstacles 


Depict 

Restncied 

Terran 


Depict 

Unrestricted 

Terran 


Depict 
Mobility 
Corridors  and 
Avenues  of 
Approach 


Depict  width,  depth,  velooty,  bank  slope, 
height,  and  potential  flood  zones 


Depict  eievaicii,  s opes  that  3*!&3  modiity, 

line  of  Sight  for  equipment  usage 


Natural  and  manmade  obstacles 


Depct  bndge  c'ass  .fcafcns  and  road 
charactenstics  suchas  curve  radius,  slopes, 
and  width 


>45’ti  slope  Hinders  or  s'avjsmovementki 

combat  formaions  unless  some  effortmade 
to  enhance  mobility.  Double  hashed  lines 
used  to  indicate  area  Depiaed  in  green  if  on 
land,  blue  if  a  body  of  water 


3145%  slope  Hinders  movementto  some 
degree,  ittle  effort  is  needed  to  enhance 
movement,  butunitscannotmoveat  prefened 
speeds  or  formations  Depcied  in  green  if  on 
land,  blue  if  a  body  of  water 


0-30%  slope  Inpcatesterrainf^of 

constrants  tomovemen^  no  need  to  enhance 
mobility  so  no  delineation  is  regu  red 


The  motay  comdor  -.sef^  is  relatri^y  of 

obstacles  and  allows  a  force  to  capitalize  on 
thepnncipies  of  mass  and  speed  Identfying 
moMily  comdors  requires  some  knowledge  of 
fnendly  and  threai'adverscry  organizations 
and  their  preferred  tactics  The  best  mobiity 
comdors  use  unrestnaed  terran  that  provide 
enough  space  for  a  force  to  movein  its 
prefened  docthnal  formaions  while  avoding 
maior  obstacles  Mobility  comdors  can  follow, 
for  example,  the  directon  of  roads,  trals, 
nvers ,  streams ,  ndgelines,  etc  An  avenue  of 
approach  (AA)  is  an  ar  or  ground  route  of  an 
attacking  force  of  a  given  size  leading  to  its 
objective  or  to  key  teman  in  its  path  The 
Identification  of  AAs  is  important  because  all 
Courses  of  Action  (COAs)that  involve 
maneuver  depend  on  avalable  AAs 


53 


The  OPD  requirements  from  Figure  23  describe  the  capacities,  or  in  this  case,  the 
features  of  each  of  the  individual  overlays  that  contribute  to  the  greater  MCOO. 
Iconography  for  the  interface  design  is  incorporated  where  appropriate.  The  color  coding 
indicates  that  the  UxVs  are  gathering  data  collaboratively.  The  two  systems  are  heavily 
coordinating  activities  at  this  stage  of  BAMCIS,  and  it  is  important  that  their  information 
exchanges  be  designed  seamlessly.  The  Marines  are  able  to  rest  and  refit  during  this 
portion  of  BAMCIS  with  only  minimal  requirements  to  monitor  the  system’s  health  and 
the  collection  of  data  through  the  building  of  the  MCOO  user  interface.  The  MCOO  task 
is  the  final  step  in  the  Make  Reconnaissance  lA  Table  and  the  third  step  in  BAMCIS. 

D.  COMPLETE  THE  PLAN 

The  fourth  phase  of  the  Troop  Leading  Steps  work  flow  is  the  C  in  BAMCIS: 
complete  the  plan.  The  tasks  associated  with  UTACC  in  this  phase  involve  developing, 
refining,  selecting,  and  submitting  mission  profiles  to  higher  headquarters  for  approval 
and  assignment  of  supporting  /  joint  assets.  The  complete  the  plan  phase  of  BAMCIS  is 
partitioned  into  seven  separate  lA  Tables. 

1.  Complete  the  Plan:  Develop  Mission  Profiles 

Six  of  the  seven  lA  Tables  correspond  to  six  different  subtasks.  The  subtasks 
relate  to  the  different  teaming  options  available  for  completion  of  the  mission:  Marines 
only;  UAVs  only;  UGVs  only;  Marines  and  UAVs  only;  Marines  and  UGVs  only;  and 
Marines,  UAVs,  and  UGVs  all  working  together. 

a.  Develop  Mission  Profiles:  Marine  Only  Profile 

The  Marine  only  profile  has  four  capacities:  identify  conditions  that  keep  UxVs 
from  partnering  further,  providing  a  route  from  assembly  area  to  objective,  providing 
imagery  of  key  terrain  features  along  the  route  and  of  the  objective  area,  and  providing  an 
estimated  time  line.  So  even  though  the  UxVs  may  not  be  partnering  fully  during  this 
profile  option,  UTACC  is  still  providing  valuable  information  to  the  Marine  only  team 
through  the  interface. 
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Figure  24.  Develop  Mission  Profiles:  Marine  Only  Profile 
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The  OPD  requirements  of  Figure  24  speeify  inputs  that  both  the  Marine  and  the 
maehine  need  to  provide  and  step  through  what  that  eommunication  might  look  like.  The 
eollaboration  on  the  interfaee  is  aehieved  in  the  form  of  reeommended  routes,  imagery, 
video  feeds,  and  adjustable  time  tables.  The  color  coding  schemes  displayed  in  Figure  24 
are  all  indicative  of  soft  interdependency  requirements,  which  would  serve  as  excellent 
areas  for  the  UTACC  design  team  to  focus  efforts  and  resources.  All  of  the  capacities  are 
things  which  the  system  can  do  with  slightly  less  than  one  hundred  percent  reliability  or 
where  assistance  is  necessary. 

b.  Develop  Mission  Profiles:  UAV  Only  Profile 

The  UAV  only  profile  has  four  capacities:  identify  conditions  that  keep  UGV  and 
Marines  from  partnering  further;  provide  areas  requiring  surveillance;  provide  the  time 
on  station  per  UAV;  and  provide  the  time  on  station  with  a  rotation  of  UAVs.  Even 
though  the  UGVs  and  Marines  may  not  be  partnering  fully  during  this  profile  option,  they 
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are  still  providing  valuable  information  to  the  UAV  only  team  through  the  interface. 
Figure  25  depicts  the  capacities  and  associated  OPD  requirements. 


Figure  25.  Develop  Mission  Profiles:  UAV  Only  Profile 
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The  OPD  requirements  for  Figure  25  are  different  than  those  of  the  Marine  only 
and  UGV  only  profiles  despite  having  similar  capacities.  This  may  also  be  evident  from 
the  drastically  different  color  coding  schemes.  The  UAV  only  color  coding  scheme 
indicates  that  there  are  some  hard  interdependency  requirements  which  should  be  avoided 
or  minimized  during  development.  Requirements  are  limited  largely  to  interface  designs 
that  allow  the  human  to  monitor  system  health. 

c.  Develop  Mission  Profiles:  UGV  Only  Profile 

As  with  the  UAV  only  profile,  the  UGV  only  profile  has  four  capacities:  identify 
conditions  that  keep  UAV  and  Marines  from  partnering  further;  provide  areas  requiring 
surveillance;  provide  the  time  on  station  per  UAV;  and  provide  the  time  on  station  with  a 
rotation  of  UAVs.  Even  though  the  UAVs  and  Marines  may  not  be  partnering  fully 
during  this  profile  option,  they  are  still  providing  valuable  information  to  the  UGV  only 
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team  through  the  interfaee.  Figure  26  depiets  these  eapaeities  and  assoeiated  OPD 
requirements. 


Figure  26.  Develop  Mission  Profiles:  UGV  Only  Profile 
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The  OPD  requirements  listed  in  Figure  26  have  a  pattern  reminiscent  of  that 
shown  in  the  UAV  only  profile.  However,  the  soft  interdependence  in  the  second  row  of 
the  UGV  only  profile  may  prove  to  be  more  favorable  for  UTACC  system  developers  as 
a  focus  area.  The  last  two  rows  of  the  UGV  only  profile  indicate  the  same  hard 
interdependencies,  which  should  be  avoided  from  a  development  perspective. 
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d.  Develop  Mission  Profiles:  Marine  and  UAV  Profile 

The  Marine  and  UAV  profile  has  four  capacities:  identify  conditions  that  keep 
UGVs  from  partnering  further,  determine  if  route  from  assembly  area  to  objective  will  be 
different  for  Marines  and  UAVs,  identify  additional  tasks  for  the  UAVs  to  conduct  in 
route  to  the  objective,  and  identify  additional  tasks  for  the  UAV  to  conduct  at  the 
objective.  Even  though  the  UGVs  may  not  be  partnering  fully  during  this  profile  option, 
they  are  still  providing  valuable  information  to  the  team  through  the  interface.  Figure  27 
depicts  these  capacities  and  associated  OPD  requirements. 


Figure  27.  Develop  Mission  Profiles:  Marine  and  UAV  Profile 
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Now  that  the  profiles  contain  two  nonhomogeneous  entities,  the  OPD 
requirements  from  Figure  27  have  grown  slightly  more  complicated.  Some  of  the  reason 
for  the  increased  convolution  is  due  to  the  tactical  situation  and  the  variable  mindsets  of 
Marines.  For  instance,  a  Marine,  under  certain  circumstances,  may  wish  to  have  the 
UxVs  move  with  the  human  team  and,  in  other  circumstances,  may  not  want  to  be  even 
remotely  close  to  the  system.  The  requirements  of  Figure  27  that  offer  potential  for 
developers,  again,  lie  in  the  second  row,  as  the  color  coding  indicates  a  soft 
interdependency.  The  human  is  locked  into  providing  input  in  the  bottom  two  rows  of 
Figure  27,  indicated  by  the  hard  interdependency  color  codes. 

e.  Develop  Mission  Profiles:  Marine  and  UGV  Profile 

The  Marine  and  UGV  profile  has  four  capacities:  identify  conditions  that  keep 
UAV  from  partnering  further,  determine  if  route  from  assembly  area  to  objective  will  be 
different  for  Marines  and  UGVs,  identify  additional  tasks  for  the  UGVs  to  conduct  in 
route  to  objective,  and  identify  additional  tasks  for  the  UGV  to  conduct  at  the  objective. 
Even  though  the  UAVs  may  not  be  partnering  fully  during  this  profile  option,  they  are 
still  providing  valuable  information  to  the  team  through  the  interface.  Figure  28  depicts 
these  capacities  and  associated  OPD  requirements. 
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Figure  28.  Develop  Mission  Profiles:  Marine  and  UGV  Profile 
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A  color  coding  pattern  emerges  again,  where  the  seeond  row  offers  the  soft 
interdependeneies,  ripe  for  design  and  development,  followed  by  hard  interdependeneies. 
The  OPD  requirements  in  Figure  28  revolve  around  the  same  eoneept  of  offering 
different  routes  for  Marines  and  UxVs;  however,  the  fact  that  the  UGVs  are  more 
restricted  by  terrain  than  UAVs  offers  additional  challenges.  Similarly,  these  restraints 
limit  the  tasks  that  the  UGV  can  conduct  in  route  to  or  at  the  objective.  Examples  are 
listed  in  the  lA  Table. 

/.  Develop  Mission  Profile:  Marine,  UAV,  UGV  Profile 

The  Marine,  UAV,  UGV  profile  is  the  most  complex  of  the  teaming  options.  It 
also  has  four  capacities:  determine  if  route  from  assembly  area  to  objective  will  be 
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different  for  Marine,  UGV,  and  UAV;  identify  additional  tasks  for  the  UGV  to  conduct  in 
route  to  objective;  identify  additional  tasks  for  the  UAV  to  conduct  in  route  to  the 
objective;  and  identify  tasks  for  the  UAV  to  conduct  at  the  objective.  Figure  29  depicts 
these  capacities  and  associated  OPD  requirements. 


Figure  29.  Develop  Mission  Profile:  Marine,  UAV,  UGV  Profile 
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The  OPD  requirements  for  Figure  29  revolve  around  the  Marine’s  decision  as  to 


whether  or  not  to  travel  together.  The  three  bottom  rows  of  Figure  29  are  hard 
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interdependencies  that  require  the  Marine  to  prepare  additional  tasks  for  the  team 
members.  The  interface  design  offers  minor  possibilities  for  interdependence  despite 
these  hard  interdependencies. 

2.  Complete  the  Plan:  Refine,  Select,  and  Submit  Profile(s) 

The  final  table  of  the  seven  Complete  the  Plan  lA  Tables  corresponds  to  three 
tasks.  These  tasks  do  not  require  much  decomposition,  and  the  relationships  of  the  agents 
are  simple.  It  is,  however,  important  to  list  the  tasks,  as  they  are  steps  requiring 
documentation  in  the  work  flow.  Figure  30  depicts  these  tasks  and  their  OPD 
requirements. 


Figure  30.  Complete  the  Plan:  Refine,  Select,  and  Submit  Profile(s) 
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The  OPD  requirements  in  Figure  30  highlight  how  information  should  be 
presented  to  the  Marines.  As  the  Marines  review  the  profiles  that  were  prepared,  it  is 
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important  that  profiles  support  a  few  interaction  mechanisms,  which  are  listed  in  the 
table.  Following  the  refinement  task,  the  Marine  then  selects  the  profile  to  be  executed 
and  submits  it  up  to  the  next  higher  unit.  This  task  closes  out  the  C  in  BAMCIS. 

E.  ISSUE  THE  ORDER  lA  TABLE 

The  fifth  phase  of  the  Troop  Leading  Steps  work  flow  is  the  I  in  BAMCIS:  issue 
the  order.  There  is  only  one  task  for  this  phase,  which  is  able  to  be  captured  in  a  single  lA 
Table.  The  lone  task  is  further  broken  down  into  the  following  subtasks:  issue  the  order 
and  conduct  three  dimensional  rehearsals.  Figure  31  captures  this  task  and  its  OPD 
requirements. 


Figure  31.  Issue  the  Order 
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The  OPD  requirements  for  Figure  3 1  reflect  that  the  system,  which  has  performed 
the  lion’s  share  of  the  work  throughout  BAMCIS  up  until  now,  is  entering  into  its  down 
cycle,  whereas  the  Marines  are  coming  off  of  theirs.  Now  that  sufficient  data  has  been 
collected  and  analyzed,  the  planning  process  nears  its  end,  and  Marines  prepare  to 
execute  their  mission.  The  5PO  is  issued  to  ensure  that  all  members  are  aware  of  the  plan. 
This  phase  of  BAMCIS  is  completed  after  rehearsals  are  conducted  with  both  a  3D 
display  via  the  interface  and  physical  walk-throughs. 

F.  SUPERVISE  ACTIVITIES 

The  final  phase  of  the  Troop  Leading  Steps  work  flow  is  the  S  in  BAMCIS: 
supervise  activities.  This  phase  possesses  five  lA  Tables  consisting  of  six  tasks, 
including:  sensor  posture,  select  formation,  the  task  module,  maintenance  alerts,  maintain 
common  operational  picture  (COP),  and  tactical  alerts  and  cueing.  The  work  compiled  by 
Rice  et  al.  (2015)  was  instrumental  in  shaping  this  task  decomposition  as  well  as  the  OPD 
requirements  for  this  phase.  A  separate  column  was  added  to  the  right  of  these  lA  Tables, 
labeled  after  the  Rice  et  al.  (2015)  Task  Analysis  Worksheets  (TAW).  Also,  the  capacity 
column  of  the  tables  identifies  terms  that  Rice  et  al.  (2015)  developed.  An  abridged 
version  of  the  Rice  et  al.  (2015)  description  for  these  terms  is  listed  under  the  TAW 
column. 


a.  Supervise  Activities:  Sensor  Posture 

The  first  task,  with  its  own  lA  Table,  is  sensor  posture.  This  task  is  distilled  down 
into  four  different  postures,  each  associated  with  its  own  capacity:  defensive,  neutral, 
offensive,  and  degraded.  The  descriptions  of  these  postures  and  their  OPD  requirements 
are  provided  in  Figure  32. 
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Figure  32.  Supervise  Activities:  Sensor  Posture 
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The  OPD  requirements  for  Figure  32  delineate  a  set  of  outputs  that  the  system 
should  provide  once  the  Marine  picks  a  sensor  posture.  The  postures  are  defined  in  the 
TAW  column.  As  color  coded  in  Figure  32,  the  UxVs  will  be  able  to  choose  a  posture  for 
themselves,  requiring  Marine  approval  after  the  fact. 

b.  Supervise  Activities:  Select  Formation 

The  next  task  under  the  S  in  BAMCIS  is  select  formation.  This  task  has  been 
decomposed  into  machine  only  formations,  and  combined  formations.  The  capacities 
represent  those  formations  which  Rice  et  al.  (2015)  determined  from  scratch  or  in  the 
case  of  a  combined  formation,  adapted  from  Marine  Corps  doctrinal  publications.  In 
either  event,  the  description  of  the  capacity  is  listed  in  the  TAW  column.  Along  with  the 
OPD  requirements,  these  capacities  and  descriptions  are  listed  in  Figure  33. 
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Figure  33.  Supervise  Activities:  Select  Formations 
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The  OPD  requirements  for  Figure  33  provide  a  list  of  outputs  that  the  system 
should  have  displayed  on  the  interface,  as  well  as  further  guidance  on  machine  team 
member  location  within  combined  formations.  The  color  coding  depicts  soft 
interdependencies.  The  robots  are  capable  of  moving  into  position  within  the  formation 
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themselves  but  could  be  assisted  from  either  of  the  other  parties  and  thus  increase 
reliability. 


c.  Supervise  Activities:  Task  Module 

The  task  decomposed  in  the  following  lA  Table  is  the  actual  task  module,  where 
tasks  are  executed  within  the  work  flow.  This  work  is  broken  down  into  the  following 
stages:  departing  friendly  lines;  insertion  and  infiltration;  actions  on  the  objective;  and  re¬ 
entry  of  friendly  lines.  The  capacities  and  OPD  requirements  are  listed  in  Figure  34. 


Figure  34.  Supervise  Activities:  Task  Module 
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The  OPD  requirements  for  Figure  34  are  derived  from  soft  interdependences  as 
indicated  with  the  color  coding.  The  requirements  offer  simple  procedures,  design 
mechanisms,  a  variety  of  purposes,  and  even  limited  cyber  considerations. 

d.  Supervise  Activities:  Maintenance  Alerts 

The  third  task  under  the  S  in  BAMCIS  is  maintenance  alerts  and  is  broken  down 
into  the  following  four  capacities:  fully,  partially,  and  non-mission  capable  sensor 
statuses  (FMC,  PMC,  NMC  respectively),  and  monitoring  fuel  levels.  These  statuses  and 
their  descriptions — as  developed  by  Rice  et  al.  (2015) — and  the  OPD  requirements  are 
listed  in  Figure  35. 
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Figure  35.  Supervise  Activities:  Maintenance  Alerts 
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The  OPD  requirements  for  Figure  35  identify  that  the  mission  must  go  on  even  in 
the  face  of  degraded  sensors.  Providing  the  ability  to  assure  Marines  of  the  status  of  the 
sensors  will  reinforce  their  confidence  in  what  the  systems  are  telling  them  and  in  the 
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systems  as  a  whole.  The  color  coding  indicates  that  these  capacities  are  hard 
interdependencies  that  rely  on  the  system  to  be  able  to  self-diagnose  and  report. 

e.  Supervise  Activities:  Maintain  COP  and  Tactical  Alerts  /  Cueing 

The  final  Supervise  Activities  lA  Table  has  two  tasks  associated  with  it:  maintain 
common  operational  picture  (COP),  and  tactical  alerts  and  cueing.  The  former  is  broken 
down  into  sending  imagery  and  data  back  to  the  COP  and  leaders;  the  latter  is  broken 
down  in  the  following  two  capacities:  recognizing  tactical  alert  scenarios  and  recognizing 
cueing  scenarios.  These  capacities  and  their  OPD  requirements  are  listed  in  Figure  36. 


Figure  36.  Supervise  Activities:  Maintain  COP  and  Tactical  Alerts  /  Cueing 
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The  OPD  requirements  in  Figure  36  are  formed  on  hard  interdependencies 
between  the  system  components  and  the  Marines.  This  means  that  the  UxVs  are  able  to 
collaborate  and  assist  one  another;  however,  very  little  room  exists  for  direct  Marine 
feedback.  In  other  words,  the  Marines  will  be  reliant  on  the  systems  to  notify  them  in  the 
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event  that  a  specified  scenario  is  tripped  into  action.  These  tasks  complete  the  S  in 
BAMCIS,  and  with  it,  they  terminate  the  BAMCIS  process. 

G.  CHAPTER  SUMMARY  AND  CONCLUSIONS 

This  chapter  presented  the  results  of  melding  the  Mission  Planning  and  Execution 
Model  with  the  Coactive  Design  Model.  BAMCIS  was  the  flow  of  work,  or  framework, 
around  which  the  Mission  Planning  and  Execution  Model  was  structured.  Inserting  that 
framework  into  the  lA  Tables,  which  are  the  design  and  analysis  tool  of  Coactive  Design, 
allowed  the  author  to  develop  multiple  observability,  predictability,  and  directability 
requirements.  These  requirements  provided  Marine-specific  insight  to  the  UTACC 
developers  and  highlighted  development  focus  areas  that  were  based  on  soft  and  hard 
interdependencies.  These  suggested  refinement  areas  offer  the  potential  for  the  greatest 
return  on  time  and  resources  spent  while  developing  capacities  and  highlighting  areas 
where  the  Marine  is  well  suited  to  support  the  machines.  This  is  often  a  support 
relationship  that  is  overlooked  in  developing  smart  systems. 

1.  UTACC  Focus  Areas:  The  Five  Feedback  Categories 

Information  is  vital  to  making  decisions  and  the  process  of  gathering  and 
disseminating  information  to  a  team  composed  of  humans  and  machines,  which  each 
collect  and  require  in  different  forms,  is  inherently  difficult.  When  conducting  the 
traditional  task  decomposition  process  associated  with  the  lA  Tables,  it  became  apparent 
that  the  information  exchanges  between  the  Marines  and  machines  could  be  sorted  into 
the  following  five  feedback  categories: 

•  Scoping  the  Area  of  Interest 

•  Scoping  the  Area  of  Uncertainty 

•  Platform  Capability 

•  Sensor  Capabilities 

•  Time  Constraints 

The  first  two  categories  are  human  judgment  calls.  In  other  words,  the  human 
needs  to  provide  feedback  to  the  system  in  order  for  it  to  then  be  able  to  make  decisions 
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and  conduct  work.  These  two  categories  require  the  ability  to  identify  the  important  areas 
and  the  ability  to  prioritize  how  the  system  approaches  work.  Within  the  last  three 
categories  the  system  provides  feedback  to  the  humans,  in  order  for  the  Marines  to  be 
able  to  make  decisions.  It  is  suggested  that  feedback  loops  be  designed  that  allow  the 
Marine  to  adjust  the  parameters  of  the  system  and  gauge  the  effectiveness  of  the 
machines  while  they  are  collecting  information.  The  direction  of  the  feedback  loops, 
whether  it  is  flowing  to  or  from  the  Marine  or  the  machine,  is  of  little  importance  as  long 
as  there  is  interplay  between  both  agents.  This  is  the  essence  of  interdependence. 

2.  Author’s  Marine  Perspective  Applied  to  the  UTACC  Focus  Areas 

From  the  author’s  perspective  as  a  Marine  infantryman,  effectively  incorporating 
these  feedback  loops  into  the  final  system  should  appear  intuitive  and  be  as  streamlined 
as  possible.  The  following  illustration  guided  the  development  of  the  lA  Tables  in  this 
chapter: 


a.  Scoping  the  Area  of  Interest 

When  scoping  the  area  of  interest,  the  machine  is  in  need  of  the  starting  location 
of  the  team  and  the  objective.  With  these  two  points  an  operating  box  (op  box)  can  be 
established  where  the  machines  will  scan  and  conduct  work.  The  size  of  this  op  box  may 
be  too  large  to  efficiently  scan  or  there  may  be  areas  within  the  box  that  are  of  no  interest 
to  the  Marine  Corps.  A  visual,  electronic  map  with  adjustable  parameters  and  a  tool  that 
correlates  the  remaining  op  box  area  with  the  sensor,  as  well  as  platform  capabilities  are 
perceived  to  be  of  great  use  to  UTACC.  If  Marines  are  able  to  graphically  see  this 
correlation  as  they  are  adjusting  the  parameters,  they  would  be  able  to  more  accurately 
and  efficiently  shave  the  areas  requiring  scanning.  Simply  put,  moving  a  boundary  a  few 
millimeters  left  or  right  on  a  tablet  might  have  the  same  perceived  impact  to  the  Marine, 
whereas  to  the  machine  that  is  required  to  conduct  the  scan  of  the  area,  it  means  another 
three  hours  and  two  passes  overhead  with  a  refueling  session.  This  could  be  time  that  the 
team  does  not  possess.  This  correlation  should  be  presented  with  a  digital  clock  depicting 
the  time  required  to  scan  and  an  icon  with  a  perimeter  related  to  the  range  of  the 
machine’s  sensors.  This  would  be  a  good  example  of  predictability. 
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b.  Scoping  the  Area  of  Uncertainty 

Scoping  the  area  of  uncertainty  can  be  accomplished  in  a  similar  manner.  Having 
just  scoped  the  area  of  interest,  the  Marine  is  left  with  a  filter  over  their  op  box  that  meets 
their  time  line.  Over  the  same  filter,  the  Marine  should  then  be  permitted  the  ability  to 
prioritize  the  areas  most  in  need  of  scanning.  Perhaps  the  area  within  a  few  hundred 
meters  of  the  team’s  starting  position  is  of  little  worry  and  would,  then,  be  prioritized 
low.  If  the  scanning  time  window  shrinks,  as  planning  timelines  often  do,  then  the  hope 
would  be  that  the  highest  priority  areas  would  be  scanned. 

c.  Platform  and  Sensor  Capabilities  and  Time  Constraints 

Other  platform  and  sensor  capabilities  not  discussed  in  the  preceding  feedback 
loop  discussions  may  have  a  substantial  impact  on  the  usability  of  the  system.  The 
interface  should,  at  a  minimum  periodically,  if  not  continuously,  update  with  machine 
location.  This  information  should  be  displayed  on  the  filters  mentioned  earlier  so  that 
Marines  can  gauge  efficiency  and  effectiveness.  This  information  exchange  would  allow 
them  to  make  adjustments  in  route.  The  Marines  need  to  be  able  to  maintain  awareness 
about  what  the  machines  are  doing  and  how  they  are  performing.  To  facilitate  this  end,  a 
system  health  graphic  is  necessary  for  the  display,  visible  on  the  interface.  However,  as 
with  all  of  these  requirements,  simplicity  is  desired.  A  battery  icon  with  a  percentage  of 
remaining  battery  life  should  be  displayed  for  each  machine  in  the  field.  A  check  engine 
light  that,  when  scrolled  over,  displays  the  exact  malfunction,  or  warning,  is  desirable,  as 
well.  The  warning  should  initially  drop  down  from  the  periphery  of  the  interface  and 
remain  for  a  few  seconds,  allowing  the  Marines  the  opportunity  to  read  it,  before 
disappearing  and  then  leave  behind  just  the  check  engine  light. 

This  scenario  was  developed  with  a  few  of  what  the  author  deems  as  the  most 
important  system  requirements.  The  focus  of  this  scenario  was  the  second  step  in  the 
BAMCIS  process,  arrange  for  reconnaissance.  A  comprehensive  BAMCIS  process 
scenario  would  become  too  convoluted  and  was  not  attempted.  For  an  inclusive 
understanding  of  the  requirements  obtained  from  this  thesis,  refer  to  the  individual  lA 
Tables. 
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V.  SUMMARIZING  RESULTS  AND  RECOMMENDATIONS  FOR 

FUTURE  RESEARCH 


This  thesis  has  two  main  impact  areas.  The  first  analyzes  the  merits  of  whether 
the  Coactive  Design  Process  is  useful  to  MCWL  in  developing  the  UTACC  system  of 
systems.  The  second  is  using  Coactive  Design  to  produce  a  list  of  design  requirements 
that  captured  complicated  concepts  like  coordination,  collaboration,  and  cooperation.  The 
author  focused  on  interface  features  and  behaviors  as  the  mechanisms  for  capturing  those 
requirements.  The  third  mechanism  suggested  by  Johnson  (2014),  not  taken  into  account 
here,  was  control  algorithms  and  is  better  left  to  the  UTACC  software  and  systems 
engineers.  The  author’s  personal  experience  as  a  Marine  Corps  infantry  officer  was  also 
taken  into  account,  not  only  when  shaping  these  design  requirements  but  also  in 
providing  perspective  to  the  UTACC  team  and  stakeholders. 

A.  SUMMARY  OF  RESULTS 

As  Johnson  (2014)  stated  “Coactive  Design  breaks  with  traditional  human- 
machine  design  approaches  by  focusing  on  effective  management  of  interdependencies 
verses  focusing  on  autonomy.”  It  has  a  foundation  in  systems  engineering  and  as  an 
iterative  design  and  development  method  is  well  suited  to  meeting  the  demands  of  a 
future  military  system  where  requirements  will  change  throughout  the  development  life 
cycle. 


1.  General  Comments 

Communication  is  key  to  any  relationship.  The  processes  for  how  information  is 
shared  so  that  decisions  can  be  made  vary  widely  from  relationship  to  relationship  and 
only  increase  in  complexity  with  the  addition  of  individuals  or  agents.  Within  the 
construct  of  human-machine  teaming,  humans  and  machines  speak  in  different  languages 
and  require  different  pieces  of  information,  often  times  in  formats  unusable  by  the  other 
agent.  The  UTACC  system’s  interface  is  the  tool  by  which  the  human  is  able  to 
communicate  with  the  robots  and  vice  versa.  It  is  in  this  medium  that  information  is 
pushed  and  pulled  by  both  human  and  machine  components  for  planning,  rehearsing,  and 
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executing  a  mission.  The  UTACC  specific  lA  Tables  address  many  elements  that  need  to 
be  incorporated  when  developing  the  interface  in  order  to  maintain  the  interdependencies 
between  the  Marines  and  machines. 

The  Marine  Corps  Troop  Leading  Steps,  BAMCIS,  were  used  to  structure  the 
work  flows  analyzed  under  the  Coactive  Design  lens.  By  using  this  concept,  of  which  all 
Marines  are  familiar,  the  SoS  is  able  to  integrate  more  seamlessly  into  the  ways  Marines 
already  gather  information  and  act.  This  reduces  the  amount  of  system  learning  required 
of  organizations  that  typically  accompanies  adoption  of  new  technology.  Additionally,  it 
accelerates  the  time  with  which  Marines  will  begin  to  experiment  with  the  technology 
and  use  it  in  creative  and  beneficial  ways  other  than  those  in  which  it  was  originally 
intended.  Therefore,  creating  a  system  that  complements  the  existing  Marine  Corps 
framework  is  critical. 

2.  Benefits  of  Coactively  Designing  UTACC 

Coactive  Design  offers  three  distinct  benefits  to  UTACC  as  it  seeks  to  grow  in 
size  and  scope  over  a  timeline  that  is  appealing  to  Department  of  Defense  (DOD) 
acquisition  officials.  These  benefits  are  (1)  DOD  familiarity,  (2)  a  resilient  system,  and 
(3)  focusing  efforts  in  a  time  and  resource  constrained  development  environment.  They 
are  elaborated  on  below. 

a.  Capitalizing  on  DOD  Familiarity  with  the  Coactive  Design  Approach 

Coactive  Design  is  an  emergent  human-machine  system  design  method  that 

gained  the  attention  of  the  Department  of  Defense  (DOD)  during  two  recent 

demonstrations.  The  first  demonstration  was  the  2013  Defense  Advanced  Research 

Projects  Agency’s  (DARPA)  Virtual  Robotics  Challenge  (VRC).  There,  Coactive  Design 

author.  Dr.  Matthew  Johnson,  working  with  the  Florida  Institute  of  Human  Machine 

Cognition  (IHMC)  earned  a  commanding  first  place  out  of  126  potential  competitors.  The 

second  demonstration  was  the  2015  DARPA  Robotics  Challenge  (DRC),  where  IHMC 

earned  top  honors  and  second  place  out  of  the  24  competing  teams.  Of  note,  both  IHMC 

and  the  first  place  winner  of  the  2015  competition  earned  the  same  point  score  during  the 

competition.  Task  completion  time  was  chosen  as  the  tie  breaker,  and  the  winning  team’s 
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creativity  in  working  around  the  bipedal  constraints  of  the  competition  during  a  few  of 
the  prescribed  challenges  allowed  it  to  shave  enough  time  to  pull  into  the  lead.  IHMC’s 
ability  to  complete  this  task  as  a  bipedal  robot  demonstrated  a  level  of  mastery  of  a  very 
complicated  robotic  function  that  was  lacking  in  the  winning  teams  prototype.  For  these 
reasons,  Coactive  Design  is,  at  the  time  of  this  writing,  being  explored  by  DARPA  for  an 
experimental,  enterprise  wide.  Pilot’s  Assistant  Program.  Further  investing  in  Coactive 
Design  for  use  with  UTACC  would  capitalize  on  the  DOD  familiarity  with  it,  and  would 
align  with  the  Marine  Corps’  Expeditionary  Force  21  (EF21)  strategic  initiative  to  remain 
on  the  cutting  edge  of  technology. 

b.  Flexibility  over  Brittleness 

The  second  advantage  offered  by  Coactive  Design  to  UTACC  is  flexibility. 
UTACC  is  a  SoS  that  will  need  to  operate  in  a  complex  environment  where  uncertainty 
will  be  highly  prevalent.  Being  able  to  perform  the  same  task  in  many  different  ways  is 
what  lA  Tables  help  identify,  rather  than  building  the  system  to  work  under 
circumstances  that  may  be  hard  to  attain  in  real  life.  Eurthermore,  when  a  system  is 
designed  with  too  much  dependence  on  the  robot  to  operate  autonomously,  and  without 
any  alternative  pathways  for  the  work  to  be  completed,  the  system  is  said  to  be  brittle. 
Coactive  Design  targets  this  brittleness  by  considering  multiple  pathways  through  a  task 
that  take  advantage  of  the  unique  capabilities  that  both  humans  and  machines  bring  to  the 
team.  As  a  result,  when  one  alternative  fails,  the  mission  may  continue  on. 

As  Dr.  Johnson  (2014)  often  stated,  “In  robotics,  if  you  do  not  plan  to  fail,  you  are 
failing  to  plan.”  When  placing  robots  into  a  teaming  environment,  designers  must 
consider  uncertainty  and  build  in  the  capabilities  to  respond  to  unexpected  events.  This 
requirement  is  addressed  by  designing  resilience  into  the  system,  which  brings  about  the 
third  advantage  offered  by  coactively  designing  UTACC. 

c.  Developing  Efficiencies  in  Design  and  Development 

The  Coactive  Design  approach  to  developing  UTACC  provided  an  excellent  cost- 

benefit  study  of  development  choices  during  IHMC’s  preparation  for  the  DRC  (Johnson, 

2014).  IHMC  had  one  and  a  half  years  to  develop  their  humanoid  robot  for  the 
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demanding  and  wide  ranging  challenges  encountered  in  the  DRC.  With  a  limited  budget, 
small  time  window,  and  host  of  issues  designed  to  instill  a  sense  of  uncertainty  over  the 
challenges,  IHMC  needed  a  means  of  focusing  their  effort  on  high  reward  development 
issues.  UTACC  would  benefit  in  a  similar  fashion  as  it  is  pressed  to  develop  a  resilient 
teaming  focused  SoS  on  budget  despite  a  host  of  software  engineering  timelines. 

As  indicated  in  the  UTACC  lA  tables,  UTACC  engineers  should  seek  to  avoid 
developing  highly  “autonomous”  recognition  capabilities  where  a  simple  cue  to  a  Marine 
equipped  with  a  superior  sense  of  situational  awareness  could  quickly  approve  or  dismiss 
a  potential  threat  or  target.  Just  as  the  IHMC  team  saved  a  lot  of  time  and  money  by  not 
investing  in  complex  perception  and  planning,  so  too  could  UTACC  (Johnson,  2014). 
Instead  UTACC  should  focus  resources  on  enabling  the  human  to  be  an  effective 
teammate,  much  as  Johnson  (2014)  did  during  the  DRC.  This  thesis  has  argued  that  the 
best  ways  of  enhancing  the  Marine’s  effectiveness  is  with  the  presentation  of  information 
collected  by  the  team,  through  (1)  the  user  interface  and  (2)  designing  for  multiple 
alternatives  in  task  completion.  Eliminating  the  100  percent  solution  (e.g.,  the  ends  of  the 
autonomy  spectrum:  full  autonomy  or  full  teleoperation)  eliminates  the  hardest  problems. 
The  Coactive  Design  method  engineers  systems  that  exploit  synergy  between  systems 
and  humans — which  is  what  teaming  is  all  about. 

B.  SUGGESTED  UTACC  FOCUS  AREAS  BASED  ON  COACTIVE  DESIGN 

When  conducting  traditional  task  decomposition  processes  associated  with  the  lA 
Tables  it  became  apparent  that  the  information  exchanges  between  the  Marines  and 
machines  could  be  sorted  in  the  following  five  feedback  categories. 

•  Scoping  the  Area  of  Interest 

•  Scoping  the  Area  of  Uncertainty 

•  Platform  Capability 

•  Sensor  Capabilities 

•  Time  Constraints 
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The  first  two  categories  are  human  judgment  calls.  In  other  words  the  human 
needs  to  provide  feedback  to  the  system  in  order  for  it  to  then  be  able  to  make  decisions 
and  conduct  work.  These  two  categories  require  the  ability  to  identify  the  important  areas 
and  the  ability  to  prioritize  how  the  system  approaches  work.  Within  the  last  three 
categories  the  system  provides  feedback  to  the  humans  in  order  for  them  to  be  able  to 
make  decisions.  It  is  suggested  that  feedback  loops  be  designed  that  allow  the  human  to 
adjust  the  parameters  of  the  system  and  gauge  the  effectiveness  of  the  machines  while 
they  are  collecting  information.  The  direction  of  the  feedback  loops,  whether  it  is  flowing 
to  or  from  the  Marine  or  the  machine,  is  of  little  importance,  as  long  as  there  is  interplay 
between  both  agents.  This  is  the  essence  of  interdependence. 

C.  RECOMMENDATIONS  FOR  FUTURE  RESEARCH 

This  work  was  only  the  initial  step  in  developing  a  coactively  designed  UTACC. 
It  has  analyzed  the  merits  of  pursuing  this  specific  design  approach  and  recommended 
that  it  be  adopted  for  the  duration  of  the  program.  Furthermore,  this  thesis  has  made 
recommendations  on  initial  system  requirements  and  bridged  much  of  the  previous 
concept  development  work  with  the  tool  that  achieves  these  requirements,  the  lA  Table. 
As  an  iterative  design  process,  truly  capitalizing  on  Coactive  Design  requires  investing  in 
it  over  the  long  term,  which  may  be  achieved  through  the  following: 

1.  System  Engineering  in  the  Program  Organizational  Structure 

The  first  recommendation  to  sustaining  the  momentum  brought  about  by  this 
thesis  is  to  incorporate  a  coactive  designer  into  the  existing  UTACC  program’s 
organizational  structure.  Figure  37  is  a  recommended  organizational  chart  that 
graphically  depicts  the  administrative  and  operational  relationships  such  a  Coactive 
Designer  would  need  in  order  to  ensure  proper  utilization. 
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Figure  37.  Coactive  Designer  in  the  Program  Organizational  Structure 


As  with  all  software  design  projects,  the  designer  and  developer  should  be  in 
constant  conversation.  Such  conversation  is  not  characterized  by  one  role  being 
subjugated  to  the  other.  Rather,  mutual  respect  for  the  insights  and  contributions  of  each 
respective  position  must  be  acknowledged.  It  is  of  critical  importance  that  the 
conversations  and  interactions  of  these  two  positions  be  physically  joined  to  the  greatest 
extent  possible.  This  is  not  limited  to  merely  working  in  the  same  building,  although  that 
would  appear  a  bare  minimum.  The  designer  and  developer  should  occupy  the  same  work 
space,  be  entwined  in  every  phase  of  the  project  from  concept  development,  requirement 
generation,  programming,  testing,  and  evaluation.  Doing  so  will  only  enhance  the 
system’s  flexibility,  benefitting  the  overall  project  resiliency. 

2.  Maintain  Momentum  by  Overlapping  Turnover  among  Designers 

As  with  any  iterative  design,  the  true  insights  come  about  after  the  designer  and 
developer  exchange  perspectives.  It  was  observed  by  the  author  that  after  holding  a  team 
meeting,  where  the  Coactive  Design  results  were  shared  with  the  normally  physically 
disparate  project  team  members  that  design  potentials  were  not  only  realized  but  were 
actually  improved  upon.  Given  the  physical  isolation  of  the  project’s  team  members,  at 
least  one  other  gathering  of  the  minds  should  be  held  where  the  author  could  conduct  a 
proper  turnover  of  knowledge  and  experience  with  his  replacement  and  more  aptly 
guarantee  a  smooth  transition  among  designers.  This  turnover  would  greatly  reduce  the 
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amount  of  time  it  would  take  to  get  a  new  designer  familiar  with  previous  work 
conducted  and  could  alleviate  many  of  the  issues  that  would  arise  should  that  new 
designer  not  have  background  working  in  the  Marine  Corps  infantry. 

3.  Designing  beyond  the  Demonstrations 

This  thesis  has  made  recommendations  for  where  UTACC  should  focus  its 
limited  efforts  within  the  many  design  requirements  identified  in  the  UTACC  lA  tables. 
Achieving  all  of  them  will  require  that  multiple  drafts  of  lA  tables  be  tied  to 
experimentation  and  the  prescribed  evaluation  of  change  processes  with  accompanying 
feedback  loops  into  the  identification  processes. 

The  set  of  scoped  recommendations  served  the  purpose  of  meeting  a  2016 
UTACC  demonstration,  which  extended  an  earlier  proof  of  concept  demonstration.  Under 
tight  time  and  resource  constraints,  the  UTACC  project  team  used  the  UTACC  lA  Tables 
to  focus  their  efforts.  The  team  selected  only  a  few  of  the  requirements  identified.  When 
moving  beyond  this  second  iteration  demo,  it  is  recommended  that  future  Coactive 
Design  selection  and  implementation  periods  be  implemented.  During  these  periods  the 
team  should  take  a  look  at  incorporating  and  expanding  the  remaining  requirements 
found  within  the  lA  Tables  of  this  thesis  and  explore  new  areas  as  UTACC’ s  scope 
grows. 


4.  Building  a  Final  Resilient  System 

Alternative  teaming  options  are  a  part  of  this  thesis.  The  UTACC  Coactive 
Design  lA  Tables  specify  three  generic  teaming  options  for  every  subtask  that  is 
specified.  The  next  step,  beyond  the  scope  of  this  thesis,  is  to  depict  the  multiple 
pathways  through  a  given  alternative.  Figure  38  graphically  depicts  what  this  would  look 
like. 
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Figure  38.  The  Pathways  through  an  lA  Table’s  Alternative  Teaming  Options 
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Sources;  Johnson,  M.,  Shrewsbury,  B.,  Bertrand,  S.,  Calvert,  D.,  Wu,  T.,  Duran,  D., 
Stephen,  D.,  Mertins,  N.,  Carff,  J.,  Rifenburgh,  W.,  Smith,  J.,  Schmidt- Wetekam,  C., 
Faconti,  D.,  Graber-Tilton,  A.,  Eyssette,  N.,  Meier,  T.,  Kalkov,  L,  Craig,  T.,  Payton,  N., 
McCrory,  S.,  Wiedebach,  G.,  Layton,  B.,  Neuhaus,  P.,  &  Pratt,  J.  (in  press).  Team 
IHMC’s  lessons  learned  from  the  DARPA  robotics  challenge:  Finding  data  in  the  rubble. 
Journal  of  Field  Robotics. 


Figure  38  is  an  expanded  lA  Table  taken  from  IHMC’s  lessons  learned  from  the 
DRC.  It  adds  several  extra  steps  to  the  analysis  of  teaming  alternatives  (represented  in  the 
right  half  of  the  figure).  A  detailed  description  of  this  process  is  beyond  the  scope  of  this 
thesis.  The  important  takeaways  include:  the  columns  identifying  which  component  will 
perform  work;  the  sub-columns  to  the  components  that  specify  the  design  requirement, 
which  controls  the  capacity;  the  ability  to  list  multiple  components  as  able  to  perform 
work;  the  ability  (through  color  coding)  to  depict  the  range  of  a  components’  ability  to 
perform  work;  and  a  means  of  physically  and  logically  tracing  multiple  paths  through  the 
workflow  to  completion  of  the  task. 

Tracing  the  alternative  pathways  through  a  task  allows  developers  to  more 
accurately  identify  where  the  soft  interdependencies  lie,  and  thus  where  development 
efforts  should  be  focused.  Furthermore,  mapping  out  these  multiple  pathways,  provides 
the  Marine-machine  team  with  alternative  ways  of  recognizing  and  handling  the 
unexpected.  The  teamwork  infrastructure’s  flexibility  is  supported  with  a  multitude  of 
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interdependent  relationships.  Naturally,  these  alternatives  should  be  a  part  of  the  training 
regime  designed  for  UTACC. 

5.  Three  Selling  Points:  Dull,  Dangerous,  and  Dirty 

When  deciding  on  future  requirements  to  pursue,  or  when  creating  new  ones, 
there  are  three  points  that  will  further  help  to  direct  efforts. 

•  What  task  is  difficult  to  do? 

•  What  is  dull  or  boring  to  do? 

•  Is  the  system  annoying  or  difficult  to  use? 

When  designing  H-M  systems,  the  goal  is  to  bring  the  human  to  the  things  that 
they  should  be  focusing  on.  The  machine  should  be  mapped  to  the  human  and  not  the 
other  way  around.  This  is  easily  stated  but  often  becomes  difficult  to  put  into  practice. 
UTACC  aims  to  reduce  the  cognitive  load  of  the  human  with  respect  to  controlling  the 
system  but  does  not  seek  to  eliminate  the  cognitive  load  entirely.  The  system 
requirements  provided  in  this  thesis  focus  on  keeping  the  greater  cognitive  or  judgment 
calls  with  the  human  so  that  they  are  not  devoting  all  of  their  cognitive  abilities  to  staring 
down  a  soda  straw  or  completing  basic  mechanistic  manipulation.  The  goal  is  not  to 
remove  the  human  operator  from  the  equation  but  to  reduce  difficulty,  remove  dullness, 
and  refocus  towards  accelerating,  when  necessary,  the  decision  loop. 

6.  Levels  of  Information 

The  concept  of  maintaining  a  common  operational  picture  (COP)  where 
information  from  UTACC  not  only  exists  and  can  be  passed  within  the  Marine-machine 
team  but  integrates  into  the  situational  awareness  of  war  fighters  at  all  levels  is  appealing. 
This  was  a  future  research  concept  listed  in  the  Rice  et  al.  (2015)  thesis  as  well.  It  merits 
re-mentioning  for  its  relevance  with  big  data  issues,  deciphering  which  data  elements  get 
passed,  and  to  which  level  of  command  they  ought  to  be  delivered. 
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7. 


Number  of  Marines  within  the  UTACC  Team 


This  thesis’  primary  contribution,  the  lA  Tables,  simplified  the  number  of  agents 
analyzed  down  to  one  Marine,  one  unmanned  aerial  vehicle,  and  one  unmanned  ground 
vehicle.  Marines  do  not  operate  as  individuals  in  the  field.  Therefore,  it  is  important  to 
define  whether  UTACC  is  being  designed  to  work  with  only  one  human  within  a  unit  or 
will  all  the  members  of  a  small  tactical  unit  in  order  to  effectively  operate  the  SoS.  If 
more  than  one  human  is  the  answer  then  further  analysis  is  needed  as  to  whether  all  of  the 
Marines  get  the  same  interfaces,  have  the  same  abilities  to  push  information  to  the 
machines,  and  make  decisions  about  what  to  have  the  machines  do.  Perhaps  the  solution 
rests  with  a  large,  interactive  tablet  display  for  the  unit  leader  with  full  administrative 
permissions  and  smaller  interfaces  that  serve  in  a  display  only  mode. 

8.  Emissions  Protections 

Due  to  the  fact  that  the  machines  are  sending  large  amounts  of  data  and 
continuously  communicating  with  the  other  members  of  the  team  and  building  a  COP 
across  all  the  levels  of  command,  the  potential  of  being  detected  by  an  adversary  comes 
into  play.  It  is  theorized  that  some  of  the  burden  of  reporting  would  be  relieved  due  to 
this  unsolicited  communication,  relieving  the  Marines  of  their  need  to  pass  position 
reports  and  elements  of  situation  reports,  as  examples.  However,  it  is  not  foreseen 
whether  or  not  additional  and  unintentional  reporting  would  be  caused  by  this  SoS. 
Further  research  is  needed  to  develop  electronic  detection  and  protection  procedures  and 
their  effects  on  reporting. 

9.  Authority  among  Machines 

Just  as  other  Marines  must  pick  up  the  slack  when  an  individual  Marine  is  taken 
out  of  the  fight  in  the  middle  of  a  mission,  so  too  must  the  other  machines  pick  up  the 
slack  when  an  individual  machine  goes  down.  The  machines,  especially  when  operating 
alone  in  the  field,  conducting  remote  mapping,  would  serve  as  easy  targets.  Additionally, 
they  have  to  battle  environmental  and  mechanical  issues.  Developing  a  rotating 
distribution  of  authority  among  the  machines  so  that  no  head  can  be  metaphorically 
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chopped  off  is  of  critical  importance.  Similarly,  by  sharing  a  COP,  the  data  gathered  by 
one  machine  will  not  be  lost  should  it  go  down. 

10.  Ethics  of  Robotics  Use  in  Defining  Military  Missions 

Developing  robotic  systems  for  use  within  the  military  brings  to  light  many  issues 
that  are  of  little  or  no  concern  in  the  public  sector.  The  incorporation  of  lethal  and  non- 
lethal  weapons,  targeting  systems,  and  invasive  surveillance  technologies  are  potential 
progressions  for  any  military  robotic  system.  Singer’s  (2009)  book.  Wired  for  War, 
discussed  how  innovative  technologies  often  develop  unanticipated  roles  as  users  gain 
familiarity  and  confidence  with  their  use.  Brutzman  et  al.  (2016)  identified  many  key 
considerations  and  constraints  that  helped  them  define  ethical  military  missions  and  their 
execution.  As  the  UTACC  system  is  developed,  incorporating  a  framework  similar  to 
Brutzman’s  et  al.  (2016)  could  identify  several  of  these  potential  missions. 

11.  Recommended  UTACC  Coactive  Design  Focus  Areas 

The  UTACC  design  requirements  presented  in  this  thesis  focus  largely  on 
graphical  user  interface  design.  Designing  this  series  of  interfaces  with  a  BAMCIS 
backbone  capitalizes  on  pre-existing  Marine  training  and  thought  processes  during  the 
planning  and  execution  phases  of  a  mission.  Incremental  development  of  theses  interfaces 
is  suggested.  It  is  essential  that  both  the  Marine-user  and  coactive  designer  are  included 
during  the  multiple  iterations  of  testing  and  evaluation.  Figure  39  provides 
recommendations  for  the  first  increment  of  coactively  designed  interfaces. 
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Figure  39.  First  Increment  Interface  Elements 
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formations,  immediate  re-tasking,  sensor  postures,  etc.) 

The  underlying  goal  of  these  interfaces  is  to  translate  information  between  the 
human  and  machine  domains  so  that  it  may  be  of  use  to  both  of  them.  These  design 
features  make  high  level  concepts  like  collaboration  for  human-machine  teaming 
achievable  under  the  UTACC  construct. 

D.  CHAPTER  CONCLUSION 

Developing  a  resilient  Marine-machine  system  capable  of  operating  under  various 
operational  contexts  and  able  to  assist  with  the  multitude  of  missions  required  of  today’s 
forces  is  no  small  task.  The  core  issue  surrounding  the  task  relates  to  getting  Marines  and 
machines  to  work  together.  Coactive  Design  was  built  upon  the  concept  of 
interdependence.  Only  after  one  understands  the  importance  of  how  these 
interdependencies  affect  the  teamwork  infrastructure  can  one  successfully  build  the 
bridge  between  the  two  agents. 
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